Certificate used for signing Denied pages

[Keith Wharton]

Hello, when accessing an HTTPS site blocked by policy, the Denied page displays a certificate error as the internal Bluecoat certificate is presented.

How can this be changed to present the local certificate from the PKI, that can be trusted?  

The local certificate is being used for SSL Interception (Proxy SGOS 6.7.x.x configured as Explicit proxy) and works ok for normal interception.

[Aboonaim Golandaz]

Dear Keith, If it is forward ssl interception then follow methods For SSL interception, you need a certificate that has the Subordinate CA attribute. You will see it in the Basic Constraint, Subject Type=CA. This allows you to sign new certificate on the fly when the users go to the HTTPS websites. There are 2 ways to create the certificate on the ProxySG: Self-signed If you create a self-signed on the proxy, it will automatically have the Subordinate CA attribute. Signed by an internal PKI of the customer If you sign it on an external CA, you must specify that you want that option. Then when you want to import it to the proxy. There should be one certificate only -----BEGIN CERTIFICATE----- MIIFZzCCBE+gAwIBAgIRAIAGPrphtEaf8EIFySc7rjcwDQYJKoZIhvcNAQEFBQAw gdwxCzAJBgNVBAYTAkdCMRcwFQYDVQQKEw5Db21vZG8gTGltaXRlZDEdMBsGA1UE ... C4Iahx/8F1hXF7VdyA1Y8NWDkM2+qnA3Cmcq1RhmLE+TsVeCbd+dR6BQfLyDdtSS SkIjjt/ZjbKR56vRw28C2+hme8wpxnt+ufpjKQVj0f4gzXucOV7SQZ/oq+3J9TGe IEm/CBAopHFzIqDHyX+7eWA5oY9jpcbxEVPpjegHEshNQekUXxyY3tqgoQ== -----END CERTIFICATE----- Only. If there is any root certificate to be added, then you must add it to SSL > CA Certificate.

[fi-da]

Normally this shouldn't happen in a explicit proxy setup where you configured SSL interception for all sites.

The "internal Bluecoat certificate" that you mentioned must be listed at Configuration > SSL > Keyrings. Check if the name of this unwanted certificate is referenced somewhere in the policy. The easiest way to do this is probably to search for the said keyring name in :8082/Policy/Current and replace it with the name of the generated CA certificate of your own PKI.

[Keith Wharton]

Thanks Guys. The issue isn’t anything around SSL Interception. It’s only the Exception page which is generated by the proxy for a denied site. It is encrypted with the appliance certificate which is not trusted. I cant see anywhere where the proxy can be configured to use the customers own certificate. The only workaround I can see is to add the appliance cert to the trusted CA store in the browser, but of course the client is not happy with this.

[fi-da]

Yeah that's what I was referring to.
The certificate is ultimately being configured in the policy. Check the policy for rules that contain the action "ssl.forward_proxy". Since you are mentioning that the problem only appears for denied requests, there is probably a misconfigured rule in the policy which only fires on exception pages. Search for the string "on_exception" in :8082/Policy/Current and check what issuer_keyring has been configured for that action. If auto has been configured or nothing at all, it will take the default value from the global appliance configuration, which you can check via

#show ssl proxy
Issuer keyring for emulated server certificates: XYZ
...
// XYZ is the keyring used for interception when nothing else is configured in the policy
# show ssl keyring XYZ
// Gives you more information about this certificate

To fix the probem you can either change the appliance config or explicitly specify the keyring of your existing CA certificate in the policy.

[Keith Wharton]

sorry fi-da, misunderstood. I'll look at the config next time I'm online with the customer and see. I know the ssl.forward proxy uses the customer pki cert