3

I read an article and there was a link certificate short introduced (about a half sentence). Now I want to know what exactly a link certificate is?

Assumption: A link certificate is used, when an old certificate is replaced by a new one. The link certificate is the new certificate signed with the old private key. So that with the old public key, the new certificate could be verified.

1

@SebastianOerding's answer is good, but I'll try a different explanation by building on the concept of a cross-certificate.

Cross certificate

Let's say you have two separate CAs, and you want the clients of CA1 (ie those with CA1 in their trust stores) to trust certs issued by CA2. You want to do this without adding CA2 to their trust store.

The solution is a cross-certificate, from the Microsoft documentation:

Cross certification enables entities in one public key infrastructure (PKI) to trust entities in another PKI. ... A mutual trust relationship between two CAs requires that each CA issue a certificate to the other to establish the relationship in both directions. The path of trust is not hierarchal (neither of the governing CAs is subordinate to the other).

PKI cross certificate

So each root issues a certificate containing the public key of the other (self-signed) root CA. This allows path validation engines to "pretend" that the self-signed root cert of CA2 was issued by the cross cert, which was issued by CA1.

Link certificate

Now, think of a link cert as a special case of a cross cert where CA1 and CA2 are two different root certs for the same CA (ie the same CA DN), but with different public keys (and likely also different expiration dates, serial number, CRL location, etc).

Root key expiry is a problem because as far as clients are concerned, it's a brand new CA. Link certs bridge that gap by telling clients that this new root cert replaces the expired one that is in their trust store.

  • thx for your answer. If I replace a root certificate with a new one and a link certificate is used, what is happening with already issued certificates which has a later experiation date than the former root certificate? is this possible, how are the certificates validated, because the new root certificate has a differrent public key – Kevin Wallis Jul 30 '18 at 7:00
  • 1
    @KevinWallis Generally a CA won't issue a cert with a longer expiration date than the CA itself, no this problem never happens. The RFC does have a condition for it though (basically the cert gets orphaned and can no longer be verified), see the last paragraph of RFC 5280, section 4.1.2.5 – Mike Ounsworth Jul 30 '18 at 11:51
2

Your assumption is correct. However to avoid a certificate path validation with expired CA certificates at the end, you can have such a link certificate and another certificate from the same CA with the same new public key which is self-signed (uses the new private key corresponding to the new public key). This way you can smoothly switch from the old CA certificate to the new one and your certificate path neither ends with an expired certificate nor it gets longer. In such a case the CA certificates should make use of the AuthorityKeyIdentifier / SubjectKeyIdentifier extensions to simplify things.

  • thanks for your answer. If I replace a root certificate with a new one and a link certificate is used, what is happening with already issued certificates which has a later experiation date than the former root certificate? is this possible, how are the certificates validated, because the new root certificate has a differrent public key – Kevin Wallis Jul 30 '18 at 6:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.