Change Details

Our big Digicert unified certificate expires at 2019-01-24T12:00:00 UTC . See also related GlobalSign ticket recently resolved at T206804 Same very basic rules apply as usual: * Fresh private keys * ECDSA+RSA * ~1yr validity * Embedded SCTs * Minimim 10 days of clock skew room between the new one's start date and the old one's expiry This means the start date on the new cert must be no later than 2019-01-14T12:00:00 UTC. Ideally, if we can, we should aim for an end date out in Feb/Mar 2020 somewhere, so that we can further increase the current 63-day spread between GlobalSign and Digicert expiries and avoid Holiday-related issues next time around, even if that means the validity on this one is a bit longer than a year (e.g. ~13-14 months). An alternative strategy that would fix the same process issues would be to get this one as a ~6-month cert. Given there's only two weeks between everyone coming back from various holidays and our maximal start date, we should try to **get the purchasing process cleaned up between now and mid-December**, so that the funding is ready-to-go from the vendor's POV before the start of the new year, and we just have technical processes to take care of during early January. I'm not sure if that's going to complicate things on our end or theirs, crossing the purchase over a CY boundary like that, but I wouldn't think so). We may eventually add LetsEncrypt as a 3rd redundant certificate sometime during 2019, and we may then also eventually choose to drop one of our two commercial vendors later if we're happy with how LE is working out, but none of those things are certain enough by Jan 2019 to impact our planning or renewal process here in any way.

Our big Digicert unified certificate expires at 2019-01-24T12:00:00 UTC . See also related GlobalSign ticket recently resolved at T206804 Same very basic rules apply as usual: * Fresh private keys * ECDSA+RSA * ~1yr validity * Embedded SCTs * Minimim 10 days of clock skew room between the new one's start date and the old one's expiry This means the start date on the new cert must be no later than 2019-01-14T12:00:00 UTC. Ideally, if we can, we should aim for an end date out in Feb/Mar 2020 somewhere, so that we can further increase the current 63-day spread between GlobalSign and Digicert expiries and avoid Holiday-related issues next time around, even if that means the validity on this one is a bit longer than a year (e.g. ~13-14 months). An alternative strategy that would fix the same process issues would be to get this one as a ~6-month cert. Given there's only two weeks between everyone coming back from various holidays and our maximal start date, we should try to **get the purchasing process cleaned up between now and mid-December**, so that the funding is ready-to-go from the vendor's POV before the start of the new year, and we just have technical processes to take care of during early January. I'm not sure if that's going to complicate things on our end or theirs, crossing the purchase over a CY boundary like that, but I wouldn't think so. We may eventually add LetsEncrypt as a 3rd redundant certificate sometime during 2019, and we may then also eventually choose to drop one of our two commercial vendors later if we're happy with how LE is working out, but none of those things are certain enough by Jan 2019 to impact our planning or renewal process here in any way.

Our big Digicert unified certificate expires at 2019-01-24T12:00:00 UTC . See also related GlobalSign ticket recently resolved at T206804 Same very basic rules apply as usual: * Fresh private keys * ECDSA+RSA * ~1yr validity * Embedded SCTs * Minimim 10 days of clock skew room between the new one's start date and the old one's expiry This means the start date on the new cert must be no later than 2019-01-14T12:00:00 UTC. Ideally, if we can, we should aim for an end date out in Feb/Mar 2020 somewhere, so that we can further increase the current 63-day spread between GlobalSign and Digicert expiries and avoid Holiday-related issues next time around, even if that means the validity on this one is a bit longer than a year (e.g. ~13-14 months). An alternative strategy that would fix the same process issues would be to get this one as a ~6-month cert. Given there's only two weeks between everyone coming back from various holidays and our maximal start date, we should try to **get the purchasing process cleaned up between now and mid-December**, so that the funding is ready-to-go from the vendor's POV before the start of the new year, and we just have technical processes to take care of during early January. I'm not sure if that's going to complicate things on our end or theirs, crossing the purchase over a CY boundary like that, but I wouldn't think so). We may eventually add LetsEncrypt as a 3rd redundant certificate sometime during 2019, and we may then also eventually choose to drop one of our two commercial vendors later if we're happy with how LE is working out, but none of those things are certain enough by Jan 2019 to impact our planning or renewal process here in any way.