Earlier today a new certificate was deployed for
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.
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.