13

I just bought a certificate from RapidSSL. Looking up the chain, I found GeoTrust who is signed by Equifax.

Then I realized that the ”Equifax Secure Certificate Authority” is due to expire on 2018-08-22 at 16:42 GMT. While my certificate is due to expire on 2018-09-01 at 01:32 GMT. GeoTrust is due to expire on 2022-05-21 at 6:00. Giving my new cert a longer lifetime than a certificate further up the chain.

What will happen in the last eight days of my certificate? Will it no longer be valid as the chain will be broken?

I came across this while assembling the chain to get OSCP working in OpenSSL. OpenSSL spewed out errors when my chain did not contain Equifax whilst browsers and other clients seemed happy with just the GeoTrust certiface without going any further up the chain. (I presume browsers assume GeoTrust to be a top-level CA while OpenSSL is not happy with them.)

openssl ocsp -issuer RapidSSL_GeoTrust_Equifax.pem \
  -cert my_rappidssl_cert.pem -url http://rapidssl-ocsp.geotrust.com

(This also affects nginx when set to OCSP staple certificate. It fails the same way OpenSSL does with an incomplete chain.)

Is there anyway I can get the last eight days of my certificate? Or should I ask for a 8-day refund?

What will happen with the GeoTrust certificate after 2018?

Daniel
  • 231
  • 2
  • 7

2 Answers2

5

GeoTrust (and RapidSSL) certs have two trust paths. There is a root cert for GeoTrust Global CA valid 2002-05-21 to 2022-05-21 and now widespread, and also a "bridge" cert for the same CA valid 2002-05-21 to 2018-08-21 chaining back to Equifax Secure Certificate Authority which as you saw is valid 1998-08-22 to 2018-08-22. See my (updated) answer to google certificates correct CA . So yes your cert will be invalid for its last few days if using the bridge+Equifax chain.

This also affects OCSP responses in your non-title questions.

I don't have a rapidssl cert to test, but if I ask gtglobal-ocsp.geotrust.com about google-CA the responder cert is also under GeoTrust Global CA. If rapidssl-ocsp does the same, OpenSSL should verify the response if the truststore contains the GeoTrust root but not the bridge cert because that can confuse chain lookup -- at least to date; 1.0.2 is announced to have changes in chain validation and I haven't looked at the details yet.

For server certs AFAIK all major browsers trust the GeoTrust root and will chain to it. I don't know they validate OCSP responses the same way (as server certs) but I would hope and expect so.

But note if your server (is configured with and) provides in handshake the bridge cert, and possibly the Equifax root -- root is always optional and unnecessary in handshake, OpenSSL client (to date as above) must have the Equifax root in truststore, it will not "discover" the alternate and better trust path to the GeoTrust root, which browsers and maybe other clients will.

Community
  • 1
dave_thompson_085
  • 9,759
  • 1
  • 24
  • 28
  • The OpenSSL trunk has a -trusted_first option which fixes this problem, and some distros have backported it I think. There is an OpenSSL bug about making it the default. – Yuhong Bao Jan 04 '15 at 01:54
  • As a side note, I think the Android browser uses OpenSSL. – Yuhong Bao Jan 04 '15 at 02:05
1

They will have to issue a new certificate before theirs becomes invalid. As long as they use the same private key to sign their new (root) certificate, your (longer valid) certificate will be accepted, as long as you trust their authority.

The certificate validity is not based upon the certificate itself, but the signature of the private key. Using the same private key to generate a new public certificate, with a new valid period, will keep the trust the same.

RedPixel
  • 131
  • 2