Change Details

Our big GlobalSign unified certificate expires at 2018-11-22 07:59, which means it's time to get the renewal going soon! The basic requirements from last time around: * We want only 1yr validity, no extended "free" deals of significant length or anything. * We want to generate the new public certs using fresh privates, not re-use existing ones. * RSA + ECDSA pair certs (no-cost re-issuance, to support certain legacy UAs that still require RSA) * Embedded SCTs (I believe this should be a given now, whereas it was a special request last time around) * We need the clock on the new cert to start at a **bare minimum** of 48 hours before the old one expires, but preferably the gap is more than 1 week to allow ample testing and no clock-skew risks on either side. If we can get it even sooner than that, it will also gain us an increasing gap between the annual renewals of the two vendors, which currently sits at 63 days. Additionally, I think we're going to take a last-minute look at whether it's reasonable to ask for the `Must-Staple` extension this time around ( T204987 ), or whether we should defer on that for now, assuming GlobalSign can do it and we decide we're operationally ready for it. I'm still on the fence on this until I re-examine everything about our current OCSP setup and latest outside info. At the very least, we probably want to resolve issues raised in T163541 first, and if we can't be comfortable with it yet this year, it's not the end of the world. //Note: the companion redundant Digicert unified doesn't expire until 2019-01-24, and will be tasked separately at a later date. Not everything is even yet decided about exactly how we'll handle that one this time around.//

Our big GlobalSign unified certificate expires at 2018-11-22 07:59, which means it's time to get the renewal going soon! The basic requirements from last time around: * We want only 1yr validity, no extended "free" deals of significant length or anything. * We want to generate the new public certs using fresh privates, not re-use existing ones. * RSA + ECDSA pair certs (no-cost re-issuance, to support certain legacy UAs that still require RSA) * Embedded SCTs (I believe this should be a given now, whereas it was a special request last time around) * We should aim for a minimum 5-day client clock skew window per stats from T196248 for the big unified. We have to watch clock skew in both directions, so e.g. if we get a start date that's 10 days before the old one's end-date, and switch exactly at the middle-point, we'll have 5 days of clock skew protection in both directions. Preferably we give a little more headroom than that, so that we don't have to switch at the exact middle point to meet this. * If we can get the new one's end date to be even earlier than the last (earlier than Nov 22), we can increase our inter-vendor spread, which currently sits at 63 days. Additionally, I think we're going to take a last-minute look at whether it's reasonable to ask for the `Must-Staple` extension this time around ( T204987 ), or whether we should defer on that for now, assuming GlobalSign can do it and we decide we're operationally ready for it. I'm still on the fence on this until I re-examine everything about our current OCSP setup and latest outside info. At the very least, we probably want to resolve issues raised in T163541 first, and if we can't be comfortable with it yet this year, it's not the end of the world. //Note: the companion redundant Digicert unified doesn't expire until 2019-01-24, and will be tasked separately at a later date. Not everything is even yet decided about exactly how we'll handle that one this time around.//

Our big GlobalSign unified certificate expires at 2018-11-22 07:59, which means it's time to get the renewal going soon! The basic requirements from last time around: * We want only 1yr validity, no extended "free" deals of significant length or anything. * We want to generate the new public certs using fresh privates, not re-use existing ones. * RSA + ECDSA pair certs (no-cost re-issuance, to support certain legacy UAs that still require RSA) * Embedded SCTs (I believe this should be a given now, whereas it was a special request last time around) * We need the clock on the new cert to start at a **bare minimum** of 48 hours before the old one expiresshould aim for a minimum 5-day client clock skew window per stats from T196248 for the big unified. We have to watch clock skew in both directions, so e.g. if we get a start date that's 10 days before the old one's end-date, and switch exactly at the middle-point, but preferably the gap is more than 1 week to allow ample testing and no clock-skew risks on either sidewe'll have 5 days of clock skew protection in both directions. If we can get it even sooner than thatPreferably we give a little more headroom than that, so that we don't have to switch at the exact middle point to meet this. * If we can get the new one's end date to be even earlier than the last (earlier than Nov 22), it will also gain us we can increasing gap between the annual renewals of the two vendorse our inter-vendor spread, which currently sits at 63 days. Additionally, I think we're going to take a last-minute look at whether it's reasonable to ask for the `Must-Staple` extension this time around ( T204987 ), or whether we should defer on that for now, assuming GlobalSign can do it and we decide we're operationally ready for it. I'm still on the fence on this until I re-examine everything about our current OCSP setup and latest outside info. At the very least, we probably want to resolve issues raised in T163541 first, and if we can't be comfortable with it yet this year, it's not the end of the world. //Note: the companion redundant Digicert unified doesn't expire until 2019-01-24, and will be tasked separately at a later date. Not everything is even yet decided about exactly how we'll handle that one this time around.//