- While using Safari 4.0.4 on Windows(I don't have a Mac so I can’t say what’s happening with Safari on a Mac), attempting to access secure web sites from a machine behind Forefront TMG 2010 RTM, Outbound HTTPS Inspection enabled, I always seem to receive this warning:
Other browsers on the same machine that make use of the Windows Crypto API(IE8, Google Chrome) seem fine.
If we click the Show Certificate button, and take a quick look at this certificate, things look OK(the CN is correct, the certificate is not expired, etc.) and the CA is trusted:
However, at a closer look, in the Details area of the server’s certificate, we can note an error about Safari not being able to check the revocation status of the server’s certificate:
What’s the revocation status of a server’s certificate ?
After a CA issues a certificate, at a various moment in time, it can revoke that certificate. Valid reasons for this are: loss/theft of the private key corresponding to the public one contained in the certificate, cease of operation, the owner now is part of a new organization, etc.
For example an attacker might manage to steal a web server’s private key, thus it(the attacker) can assume the identity of this server for SSL/TLS communications. The real owner of this certificate can ask the CA to revoke it, so that clients be aware that this certificate is no longer valid(without waiting for the certificate to expire).
How does a client check for the revocation status of a certificate ?
There are two main possibilities: by CRL or by OCSP.
A CRL(Certificate Revocation List) can be published by a CA. This is a list signed by the CA, containing the serial numbers of the certificates revoked.
The downside with CRLs is that they can become quite big. To minimize the impact of this, Delta CRLs can be used. A Delta CRL includes only entries for certificates that have been revoked since the complete CRL(aka Base CRL) referenced in this delta CRL was issued.
Or the client can use OCSP(Online Certificate Status Protocol). We’ve spoken a little about it here. The client will query an online responder about the status of the server’s certificate, the OCSP response should contain less info than a CRL.
How a client knows to find a CRL or an online responder ?
When a CA signs a certificate, based on its configuration, can add to this certificate a CDP(CRL Distribution Point) indicating the location of the CRL and in the AIA(Authority Info Access) area to specify the online responder’s URL(if there is one). If both are present in the server’s certificate, and the client supports them both, based on its settings, the client might prefer OCSP.
Note that some clients might be unable in the first place to use OCSP(most modern browsers should be able to do that).
Is mandatory for a CA to make available(either through CRL or OCSP) the revocation status of a certificate ?
No really, unless it’s an EV(Extended Validation) certificate. Obviously if a client cannot check the server’s certificate status, there is no way to revoke that certificate, other than not trusting the CA that issued it(which would make the client to not trust the server’s certificate), or if the client permits to manually flag a specific certificate as untrusted.
Is mandatory for a client to check the status of a server’s certificate ?
The answer may complicate on this one. It may vary depending on a client.
As a general short note, the client should check the status of a server’s certificate.
So what happened above with Safari on Windows through TMG 2010 applying HTTP Inspection ?
After conducting some tests without TMG on the path, with a custom CA and a custom secure web server, I’ve noticed that Safari 4.0.4 on Windows will throw that error when the server’s certificate will not contain any information regarding how to access status information about that certificate. It seems that a revocation status check over the server’s certificate is mandatory(either by design or by accident, can’t tell for sure right now).
When creating and signing an on-the-fly the temporary server certificate(so that HTTPS Inspection to be applied), TMG removes any CDP or AIA fields.
Why is that ?
Quick answer: because they are no longer applicable(valid) for the new on-the-fly temporary server certificate.
TMG does the revocation check itself(looks like it’s able to use OCSP too).
Basically speaking there is no revocation check that the client can make(from a certain point of view). The on-the-fly temporary server certificate contains TMG’s RSA public key from its certificate(root certificate) used to perform outgoing HTTPS inspection, the on-the-fly server certificate mimics the real server’s one(actually, for example, if you go to mail.yahoo the same temporary certificate might be used for a period of time with different clients(if I reboot TMG a fresh on-the-fly one will be created)). If the associated public key with such a certificate becomes compromised, that would imply that TMG’s private key itself becomes compromised, thus clients should be configured to not trust anymore TMG’s root certificate.
As a side note, such a check from the clients themselves will introduce additional delay.
For the moment being, only clients that have a certificate status mandatory check(either through CRL or OCSP) will threw warnings/errors behind Forefront TMG 2010 while Outbound HTTPS Inspection is enabled. This questions the feasibility of applying the Forefront TMG 2010’s outbound HTTPS inspection for them.
Enabling, for example, TMG to add CDP entries to an on-the-fly temporary server certificate, means that (probably) TMG (itself) should be able to respond to CRL download requests from clients. As writing, TMG simply strips the CDP and AIA fields from the real server’s certificate.
How to fix the above issue with Safari 4.0.4 on Windows ?
Quite honestly I don't know. Looking at some settings of interest on Safari, I can’t see from where to not make mandatory the certificate status check.
Note that other browser do check the certificate’s status, however they do not complain when CDP or AIA OCSP info is missing from the server’s certificate.
As temporarily workarounds:
- more brutal: add the clients(machines) using Safari 4.0.4 on Windows to the Source Exceptions list of the Outbound HTTPS Inspection. Not recommended ,as it disables globally the Outbound HTTPS Inspection for those clients.
- use a different browser.
- contact Apple’s support.
- While using Opera 10.01 on Windows, attempting to access secure web sites behind Forefront TMG 2010 RTM, Outbound HTTPS Inspection enabled, I always seem to receive this warning:
If I continue Opera displays this(for the security details of this connection, the SSL/TLS padlock is a question mark):
I can confirm I’ve added the TMG’s certificate used for HTTPS Inspection to the trusted CA store on Opera:
How to fix the above issue with Opera 10.01 on Windows ?
- when you import a CA certificate on Opera 10.x, the Warn me before using this certificate checkbox is checked by default(an extra security precaution, you can uncheck it during the import procedure though, see bellow). Uncheck this checkbox as described in this picture if you’ve already imported TMG’s certificate on Opera:
- or make sure that during the import procedure you uncheck the above mentioned checkbox:
