The Security MVPs have a private mailing list on which we gather to share expertise or our interesting findings – the following was raised by an MVP, and very much interested me, on a number of levels:
The US Postal Service has a web service (as well as a physical method) for signing up to have your mail held if you’re not going to be able to check on it for a while.
This service represents a number of lessons in privacy and security.
First, let’s look at the web site itself, at least as it was this morning (the certificate error has been fixed since then):
Okay, I don’t know about you, but that’s not what I expect to see when I go to the post office.
[For those of you using a search engine to reach this page, the text reads:
There is a problem with this website’s security certificate.
The security certificate presented by this website was not issued by a trusted certificate authority.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage and do not continue to this website.
Click here to close this webpage.
Continue to this website (not recommended).]
If you’re anything other than someone trying to research this issue and see its cause, then I suggest you follow the browser’s recommendation right now and close the webpage. This page is broken, just as if it was displaying any other error. It is not an appropriate use of Internet security technology to “Continue to this website (not recommended)”. Really.
So, let’s show you what we get when we do continue to the website:
The web page certainly looks like the rest of the USPS web site – same colours, same graphics, etc. But all that can be easily faked. What about the part that isn’t so easy to fake, the certificate that tells me that this really is a usps.gov web page? No, that’s a problem, as you can clearly see from the “Certificate Error” message.
Note that if this had been a bad page pretending to be the USPS, we would possibly have just started running evil code, designed to take over our system, steal our information, and generally mess with our lives. This is why I said earlier that you should just leave it alone, think of it as a broken page, and not deal with it any more. Unless you’re trying to debug the problem in the web server.
Let’s see what the details are of the Certificate Error (Microsoft, take note – it’s a bad thing that you have to visit the page in order to view its certificate from within IE!):
Okay, that’s pretty much what the other page said – the certificate this web site gave us was not issued by someone we trust.
Let’s view the certificate and find out more about it:
“This certificate cannot be verified up to a trusted certification authority”, huh?
[An interesting note here is that the certificate is issued to “*.usps.gov” – this is a wildcard certificate, and is generally expensive to get, and requires some understanding of certificates and how to safely manage them, because a wildcard certificate is open to abuse if it escapes. Bear that in mind as you read on.]
Why can’t we verify the certificate chain?
If you’ve only ever bought a Verisign certificate, you’ve probably got a certificate that’s signed directly by a trusted root certification authority (CA).
That means that the “Issuer” identified in the certificate is already installed in everyone’s “Trusted Roots” certificate store when your operating system was first installed. But that doesn’t always have to be the way.
Certificates can, in fact, be issued by subordinate Certificate Authorities (CAs) – and those subordinate CAs have their own certificates that are issued by other CAs, and so on up to an eventual root CA, whose certificate is installed in your clients’ systems.
So what’s the problem here? This certificate says it’s issued by “Comodo Class 3 Security Services CA” – isn’t that good enough?
Not for the browser – remember, it’s not a human, and doesn’t know how to get a hold of “Comodo Class 3 Security Services CA” to tell if it’s a valid issuer, and part of a chain up to a trusted root. It needs to be given a certificate, or told how to find it.
Let’s look at the Extensions in the certificate, and see what might be of use there:
Okay, so a CRL Distribution Point is a list of places where a Certificate Revocation List (CRL) might be published – and a CRL will tell the browser whether or not this certificate has been declared unsafe. Oh, if only there was such a Distribution Point for the issuer’s certificate!
There is, of course, or I wouldn’t be leading you there.
Let’s take a look at Microsoft’s secure certificate extensions:
No, because actually, that’s not the only way to provide an Intermediate CA’s certificate. It’s the only way that guarantees that the certificate chain can be checked no matter how the certificate can be delivered, but SSL / TLS give you an extra opportunity to fix this.
In the SSL handshake, where the server gives its certificate to the connecting client, there’s the possibility for the server to give several certificates – a chain, in fact, from its own certificate all the way up to its root, if necessary.
The Post Office can – and did – ensure that the server gives out its own certificate and the rest of its chain.
I’m not much of a web administrator – in fact, I know next to nothing about web servers. However, I have been told that in Windows, all you need to do is import the intermediate CA’s certificate, and the server will automatically give it out to the client.
The basic lesson here is that you need to test your certificates on a system that isn’t in your domain and doesn’t have any of the imported certificates that you might already have fetched from your dealings with your CA.
You need to discover if your CA put a valid AIA in your certificate when it issued it, and if it didn’t, then at least import the intermediate CA’s certificate into your server, so that it’s ready to go.
But this page made me think about more than how to fix the lack of Intermediate CA… more next time.