Backdating certificates
Earlier today a new certificate was deployed for f2.shared.global.fastly.net
:
Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign CloudSSL CA - SHA256 - G3
Validity
Not Before: Nov 15 11:18:20 2018 GMT
Not After : Sep 7 16:10:08 2019 GMT
Subject: C=US, ST=California, L=San Francisco, O=Fastly, Inc., CN=f2.shared.global.fastly.net
It was deployed only a few minutes after the Not Before
time. One of our users had their system clock lagging behind slightly which caused them to receive certificate errors.
Even though this is a user error, I want to suggest backdating certificates if possible, or wait a while until you deploy them after generating them.
-
Official comment
Hello @ericmj,
The way these shared certs are re-issued is when there is a change made to the TLS Certificate; either a new SAN addition or a SAN removal. The lion's share of situations where contemporaneous re-issue of a cert is done is much, much greater than those situations where one wants us to wait.
If you can imagine when an entity wants to add to our shared cert, they want to have their domain ready for traffic. In the other situation, the removal of a SAN may be critical to a billing issue for another entity. Both these situations support a quick re-issue of the certificate.
It is unfortunate that some system clocks may not be sync'd properly, however, we as a company strive to address the situations that would best serve our community. Swift deployment of TLS certs is heavily favored over a delay in deployment.
We do have a product where the issue with "not before" time is minimized. A cert under your control is best where timing is this important. We call this the Fastly Hosted Certificate where you upload a TLS certificate and it's key to us, and we deploy it to our edge. In this way, you will know for sure both the "not before" and " not after" times and can plan accordingly.
Comment actions
Please sign in to leave a comment.
Comments
1 comment