SonicWALL TZ 190 Manuale Utente

Common-Name based 
White and Black Lists

The administrator can define lists of explicitly allowed or denied 
certificate subject common names (described in Key Concepts). 
Entries will be matched on substrings, for example, a blacklist 
entry for “prox” will match “www.megaproxy.com”, 
“www.proxify.com” and “proxify.net”. This allows the administrator 
to easily block all SSL exchanges employing certificates issued to 
subjects with potentially objectionable names. Inversely, the 
administrator can easily authorize all certificates within an 
organization by whitelisting a common substring for the 
organization. Each list can contain up to 1,024 entries.

Since the evaluation is performed on the subject common-name 
embedded in the certificate, even if the client attempts to conceal 
access to these sites by using an alternative hostname or even an 
IP address, the subject will always be detected in the certificate, 
and policy will be applied.

Self-Signed Certificate 
Control

It is common practice for legitimate sites secured by SSL to use 
certificates issued by well-known certificate authorities, as this is 
the foundation of trust within SSL. It is almost equally common for 
network appliances secured by SSL (such as SonicWALL security 
appliances) to use self-signed certificates for their default method 
of security. So while self-signed certificates in closed-
environments are not suspicious, the use of self-signed certificates 
by publicly or commercially available sites is. A public site using a 
self-signed certificate is often an indication that SSL is being used 
strictly for encryption rather than for trust and identification. While 
not absolutely incriminating, this sometimes suggests that 
concealment is the goal, as is commonly the case for SSL 
encrypted proxy sites.

The ability to set a policy to block self-signed certificates allows 
security administrators to protect against this potential exposure. 
To prevent discontinuity of communications to known/trusted SSL 
sites using self-signed certificates, the whitelist feature can be 
used for explicit allowance. 

Untrusted Certificate 
Authority Control

Like the use of self-signed certificates, encountering a certificate 
issued by an untrusted CA isn’t an absolute indication of 
disreputable obscuration, but it does suggest questionable trust.

SSL Control can compare the issuer of the certificate in SSL 
exchanges against the certificates in the SonicWALL’s certificate 
store. The certificate store contains approximately 100 well-known 
CA certificates, exactly like today’s web-browsers. If SSL Control 
encounters a certificate that was issued by a CA not in its 
certificate store, it can disallow the SSL connection.

For organizations running their own private certificate authorities, 
the private CA certificate can easily be imported into the 
SonicWALL’s certificate store to recognize the private CA as 
trusted. The store can hold up to 256 certificates.