I have sometimes run into a situation where I see a root CA certificate which is set to expire sooner than the intermediate CA certificate.

My question is - if you were interested in keeping your intermediate CA active, and needed to update it to reference a newly created root certificate, what about the intermediate CA would need to change? I believe this is the Issuer field, but is this able to be dynamically updated like some SANs are, or do you need to update the intermediate CA certificate as well?

I guess this could also be summarized as - where in a certificate does it point to who you are signed by and what does it look like?

Bonus points for answering where in the handshake process does the certificate chain get presented to the client, and what makes this necessary (I assume it is completely client-directed as some clients do not require the server to present the certificate chain to verify a server cert's legitimacy)?

3 Answers 3


Within SSL/TLS, the server sends its certificate chain systematically to the client (well, unless the client wants to negotiate a cipher suite that uses no certificate at all, but that's pretty rare in practice). See the TLS standard, in particular this diagram, which says it all:

  Client                                               Server

  ClientHello                  -------->
                               <--------      ServerHelloDone
  Finished                     -------->
                               <--------             Finished
  Application Data             <------->     Application Data

         Figure 1.  Message flow for a full handshake

For (much) more complete explanations on how SSL/TLS works, read this answer.

Note, though, that while SSL/TLS formally relies on X.509 certificates, the protocol is not irremediably married with X.509. Within the handshake dynamics, the idea is that the server sends its public key to the client within a certificate chain, and then the client somehow uses the server's public key. How the client obtains the server's public key is a bit out of scope; normally, the client does so by decoding and validating the certificate chain sent by the server, but the client is free to "know" the server's public key from any other way that it sees fit. In some dedicated applications (especially embedded systems), the client may contain a hardcoded copy of the server's public key, and just use that, completely disregarding whatever the server sends as "certificate chain".

Moreover, the "certificate chain", from the point of view of SSL/TLS, is a sequence of opaque blobs, such that the total length does not exceed 16 megabytes. While these blobs are normally encoded X.509 certificates, they may be something else, as long as the client agrees (and a client who ignores the server certificate chain will, by definition, agree to anything). There is even a formally defined RFC for using OpenPGP keys instead of X.509 certificates in SSL/TLS.

IF the certificate chain follows the usual rules (X.509 certificates, that the client validate), then the X.509 rules apply. The complete X.509 path validation algorithm is a work of the Devil to confuse and corrupt good men's minds. However, as a simple summary, an issued certificate (your "intermediate CA certificate") matches its issuer (in your case, the root) through the two following properties, which must all be fulfilled:

  • The subjectDN field in the issuer (root) must be equal to the issuerDN field in the issued (intermediate CA). Thanks to the multitude of possible encodings and Byzantine Unicode rules for case matching, actual "equality" of names is a potentially complex notion.

  • A certificate is signed; the signature on the issued certificate must be verifiable with regards to the issuer's public key.

Therefore, if you want to keep the intermediate CA certificate unchanged, then, at the very least, the new root will need to use the exact same name as the old one, and also the exact same key pair. If you change either (or both), then you will need to reissue a new certificate for the intermediate CA.

The same principles apply down the chain: if you change the intermediate CA certificate, then you might still keep end-entity certificates unchanged (the certificates previously issued by the intermediate CA), if (and only if) the new intermediate CA certificate still contains the same intermediate CA name and intermediate CA public key.


There is actually very little in the TLS specification itself about certificate verification. The TLS specification is sufficiently flexible to allow for types of authentication other than X.509 certificates, such as OpenPGP certificates or Kerberos.

There are some expectations and references to X.509-related concepts, such as the certificate_authorities list for client-cert authentication, the definition of certificate_list in the Server Certificate message, and the meaning of some alert messages.

That said, the certificate chain is rather opaque as far as the TLS specification is concerned. One of the main points is in Appendix D:

D.2. Certificates and Authentication

   Implementations are responsible for verifying the integrity of
   certificates and should generally support certificate revocation
   messages.  Certificates should always be verified to ensure proper
   signing by a trusted Certificate Authority (CA).  The selection and
   addition of trusted CAs should be done very carefully.  Users should
   be able to view information about the certificate and root CA.

The verification process tends to rely on other specifications: RFC 5280 (or still RFC 3280) for the PKI aspect, that is, the verification of the chain, and RFC 6125 for the name verification (or still RFC 2818 and other protocol-specific specifications).

As a general rule, the Issuer Distinguished Name of a certificate should be Subject Distinguished Name of the certificate of the CA that issued it. As for alternative names, the specification says: Issuer Alternative Name

   As with Section, this extension is used to associate Internet
   style identities with the certificate issuer.  Issuer alternative
   name MUST be encoded as in  Issuer alternative names are not
   processed as part of the certification path validation algorithm in
   Section 6.  (That is, issuer alternative names are not used in name
   chaining and name constraints are not enforced.)

(You'd also need to re-use the same key material if you still want the public key in the CA cert to verify the certificate's signature.)


The summary answers you wanted:

  • The Issuer field is a DN which identifies who signed the certificate.
  • A DN (Distinguished Name) is one of those wacky "C=US, O=HAL, OU=Discovery One, CN=Dave Bowman" strings
  • But having the right name only counts if you're in the local trusted roots!

But to your main question - nothing needs to change about the Intermediate certificate in order to reference a newly updated Root certificate. It is possible to issue a new certificate for the root without invalidating the old one or breaking the link to the intermediate cert. The "Issuer" is a string, not a serial number, and so a same-name reissue of the root certificate that is properly placed in the trusted store can extend the expiration over the original.

I ran into a case of this last month; I have a cert that is signed by the Entrust L1C intermediate cert, which is in turn signed by CN=Entrust.net Certification Authority (2048). The copy of that root certificate was as follows up until recently:

    Version: 3 (0x2)
    Serial Number: 946059622 (0x3863b966)
Signature Algorithm: sha1WithRSAEncryption
    Issuer: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)
        Not Before: Dec 24 17:50:51 1999 GMT
        Not After : Dec 24 18:20:51 2019 GMT
    Subject: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)

During an OS upgrade in late January, the root certificate was quietly replaced with a newer version. Note that the serial number and validity dates change, but that the Issuer string does not:

    Version: 3 (0x2)
    Serial Number: 946069240 (0x3863def8)
Signature Algorithm: sha1WithRSAEncryption
    Issuer: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)
        Not Before: Dec 24 17:50:51 1999 GMT
        Not After : Jul 24 14:15:12 2029 GMT
    Subject: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)

Given those two different root files, openssl correctly verified the certificate chain using either one:

$ md5sum entrust.*.pem
da9ff9cd8e8e2256e9efcf5c4ef3891f  entrust.L1C.pem
244f3bbf6b112e7d399342c097db22a5  entrust.new.root.pem
0315b2915a0f74cc3498cfdd54933452  entrust.old.root.pem
$ openssl verify -CAfile entrust.old.root.pem entrust.L1C.pem
entrust.L1C.pem: OK
$ openssl verify -CAfile entrust.new.root.pem entrust.L1C.pem
entrust.L1C.pem: OK

For bonus points:

The TLS handshake generally starts like this:

C -> S Client Hello

S -> C Server Hello

S -> C Server Certificate

And the certificates are sent in a stream, from most specific -> intermediate -> root. You can actually grab the bytes from a sniffer like Wireshark and save them to a file and treat them like a .der (binary encoded certificate). I did that with the certs above and used openssl to translate them from .der to .pem for my convenience.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .