Cisco Cisco Web Security Appliance S160 User Guide
192
I R O N P O R T A S Y N C O S 6 . 3 F O R W E B U S E R G U I D E
to perform the SSL handshake with the client, it must send the client its own digital
certificate. However, the client expects the certificate of the requested server, so the
appliance mimics the requested server’s certificate by specifying a root certificate
authority uploaded or configured by an appliance administrator.
certificate. However, the client expects the certificate of the requested server, so the
appliance mimics the requested server’s certificate by specifying a root certificate
authority uploaded or configured by an appliance administrator.
For more information about how the server mimics the server’s certificate, see “Mimicking
the Server Digital Certificate” on page 192.
the Server Digital Certificate” on page 192.
Note — Because the appliance signs the server certificate with a different root certificate
authority and sends that to the client, you must verify the client applications on the
network recognize the root certificate authority. For more information, see “Working with
Root Certificates” on page 193.
authority and sends that to the client, you must verify the client applications on the
network recognize the root certificate authority. For more information, see “Working with
Root Certificates” on page 193.
After the two separate HTTPS connections are established, the following actions occur:
1. Encrypted data is received from the server.
2. The temporary, symmetric key negotiated with the server is used to decrypt the data.
3. Access Policies are applied to the decrypted traffic as if it were a plaintext HTTP
connection. For more information about Access Policies, see “Access Policies” on
page 149.
page 149.
4. Assuming the Access Policy group allows the client to receive the data, the data is
encrypted using the temporary, symmetric key negotiated with the client.
5. Encrypted data is sent to the client.
Note — No decrypted data is cached. However, access logs for decrypted HTTP transactions
are saved to disk.
are saved to disk.
Mimicking the Server Digital Certificate
When the appliance performs the SSL handshake with the client, it mimics the server digital
certificate and sends the new certificate to the client. To mimic the server digital certificate, it
reuses most field values and changes some field values.
certificate and sends the new certificate to the client. To mimic the server digital certificate, it
reuses most field values and changes some field values.
The mimicked certificate is the same as the server certificate except for the following fields:
• Issuer. The issuer comes from the generated or uploaded root certificate configured in the
appliance.
• Signature Algorithm. This field is always “sha1WithRSAEncryption” or “dsaWithSHA1”
depending upon on whether the root certificate the appliance uses contains an RSA or
DSA key.
DSA key.
• Public Key. The appliance replaces the public key in the original certificate with a public
key it generates that matches bit strength from the original certificate and for which it has
a matching private key generated as well. For example, if the server certificate uses a 2048
bit RSA key, the appliance generates a new 2048 bit RSA key.
a matching private key generated as well. For example, if the server certificate uses a 2048
bit RSA key, the appliance generates a new 2048 bit RSA key.
• X509v3 Extensions. All X509v3 extensions are removed except for the following: