{"id":773,"date":"2009-03-16T22:15:36","date_gmt":"2009-03-17T03:15:36","guid":{"rendered":"http:\/\/unitstep.net\/?p=773"},"modified":"2009-03-16T22:15:36","modified_gmt":"2009-03-17T03:15:36","slug":"using-the-basic-constraints-extension-in-x509-v3-certificates-for-intermediate-cas","status":"publish","type":"post","link":"https:\/\/unitstep.net\/blog\/2009\/03\/16\/using-the-basic-constraints-extension-in-x509-v3-certificates-for-intermediate-cas\/","title":{"rendered":"Using the Basic Constraints extension in X.509 v3 certificates for intermediate CAs"},"content":{"rendered":"

It’s not often that you’ll be creating your own X.509 certificates for a web server, since any certificates that you create (self-signed or signed by your own CA) will not be trusted by most browsers (IE, Firefox, etc.) since they were not signed by one of the many Certificate Authorities (CAs) that have been automatically trusted by the browser. If you do decide to use one of these certificates on your web server, you’ll have to navigate through a Byzantine series of screens to “confirm” that you trust the server’s certificate<\/a>. (Though this is annoying, it may be ultimately beneficial in today’s era of phishing and other malicious behaviour.)<\/p>\n

<\/p>\n

A bit of background<\/h2>\n

However, what I want to discuss today relates to certificate chains<\/em>. At the top of every certificate chain is a root CA<\/strong>, whose certificate is self-signed<\/em>. This sort of certificate can be considered a “God certificate” because it essentially says, “Trust me, because I say so”<\/em>. As you can imagine, that’s not much of an argument for trusting someone, so that is why your browser has a list of default root CAs<\/em> that it automatically trusts. <\/p>\n

\n\"basic-constraints-0\"<\/a>
\nSome default trusted CAs in Firefox.\n<\/p>\n

These root CAs are owned and operated by companies that are in the business of issuing certificates<\/em> to other people for use on their servers. They have been added to the default trusted list of most browsers so that an end user doesn’t need to manually add all of them; doing so would be a usability nightmare. Essentially, these root CAs provide a trust anchor point<\/strong>, as not only are they trusted, but any certificates they issue will also be automatically trusted by the browser<\/em>. Attempting to visit a HTTPS\/SSL website that does not have a trusted certificates results in a nasty warning from modern browsers<\/a>.<\/p>\n

Rarely is the root CA certificate directly used for a web server, but instead it is used to sign or issue other certificates<\/strong> that are then used on a web server to confirm its identity and provide for secure end-to-end communication.<\/p>\n

As you can imagine, operating a CA is an immense responsibility, so that is why these default lists have been setup: Essentially these companies have to vet entities that purchase certificates from them, to make sure they actually own the domain that they are trying to buy a certificate for, otherwise phishing would become too easy! Even so, these companies sometimes still have lapses due to use of outdated technologies and poor security practices<\/a>, but that is another complicated issue for another day.<\/p>\n

Issuing a certificate – An example<\/h2>\n

The act of issuing a certificate<\/strong> essential entails a CA using its public-private key pair to sign the contents of the certificate that is being issued. This ties the identity information in the certificate to its key pair and provides confirmation that the CA has affirmed the authenticity of the certificate, I.E., that it has truly issued this certificate and that it has not been forged.<\/p>\n

Going back to a certificate chains, it was previously mentioned that the root CA certificate is at the top of the chain. Any certificates it issues are directly below it, so if these certificates are directly used on a web server, then the chain is of length two. However, certificate chains can be longer. If a certificate chain is longer than two, then this indicates the presence of an intermediate CA<\/strong>.<\/p>\n

An intermediate CA is a CA that does not have a self-signed certificate but still has the capability to issue certificates that are trusted. For an example of the root CA to intermediate CA relationship, we can look at the certificate chain returned from https:\/\/mail.google.com<\/a>:<\/p>\n

\n\"basic-constraints-1\"<\/a>
\nThe Root CA certificate from VeriSign, an X.509 v1 certificate.\n<\/p>\n

Above we see the root CA certificate<\/em>, a self-signed certificate created\/issued by VeriSign<\/strong>. I’ve highlighted the fact that it is an X.509 version 1<\/strong> certificate, which also means it doesn’t have any certificate extensions<\/strong>. This may not mean much right now, but we’ll get back to it soon.<\/p>\n

\n\"basic-constraints-2\"<\/a>
\nThe Intermediate CA certificate from Thawte, an X.509 v3 certificate.\n<\/p>\n

This next shot shows the intermediate CA certificate<\/em> that was issued by the root CA. This certificate has been issued to Thawte<\/a><\/strong>, a company coincidentally founded by Mark Shuttleworth, the South African man behind Canonical\/Ubuntu. Thawte was acquired by VeriSign during the dot-com craze for US $575 million.<\/p>\n

\n\"basic-constraints-3\"<\/a>
\nThe “Basic Constraints” extension of the intermediate CA.\n<\/p>\n

We can clearly see that this certificate is an X.509 version 3<\/strong> certificate, meaning it does support certificate extensions. One of its extensions is a Basic Constraints<\/a><\/strong> extension, which has been set to signify that this is indeed a Certificate Authority. It also specifies one other parameter, which is the maximum number of intermediate CAs allowed beneath<\/em> this one in the certificate chain hierarchy. Since this value is set to 0, this means this intermediate CA cannot<\/strong> issue any more CA certificates, but instead can only issue client certificates<\/strong>. Any attempt will to use a client certificate from this CA as a CA or signing certificate will fail, when consumed by a conforming client.<\/p>\n

The client certificate<\/h2>\n

The last screenshot shows the client certificate<\/strong>, which is the last certificate in the chain. This is the certificate that is used by the server at mail.google.com<\/code> to secure HTTPS traffic, and as we can see, it is also an X.509 v3 certificate (has extensions) and one of those extensions is the “Basic Constraints” extension. This time it is set to indicate that this is not<\/strong> a CA certificate.<\/p>\n

\n\"basic-constraints-4\"<\/a>
\nThe Basic Constraints of the client certificate, indicating it is not<\/strong> a CA certificate.\n<\/p>\n

Basic Contraints – Why it’s needed<\/h2>\n

The “Basic Constraints<\/strong>” extension is one way for a CA to control the usage of the certificates it issues. For instance, when the root CA certificate in the example above issued the intermediate CA certificate, it set the Basic Constraints extension to signify that:<\/p>\n