5 ms·

Does anyone know what endpoint's certificate had expired? Would be interesting what CA they used for it and if it's a SAN certificate. Edit: here's the certif

by ce4 7y ago

Does anyone know what endpoint's certificate had expired? Would be interesting what CA they used for it and if it's a SAN certificate. Edit: here's the certificate log of the teams subdomain but I couldn't find the one that expired today in it https://crt.sh/?q=teams.microsoft.com https://crt.sh/?q=teams.microsoft.com

chrishas35 7y ago
There were no end-user visible certificate errors during the outage, so I suspect it was an internal/backend cert.
notimetorelax 7y ago
MS has internal CA, it’s most probably some internal back-end talking to some other internal service.
tialaramex 7y ago
> if it's a SAN certificate All certificates in the Web PKI are obliged to use SAN (Subject Alternative Name). Although it is often mistaken for some sort of aliasing feature, SAN is the Internet's agreed alternative way to name things. X.509 is intended as part of the X.500 directory system, a global directory system which obviously was never actually built, and so its built-in name scheme doesn't resemble anything that actually exists. When Netscape invented SSL back in the 1990s they hijacked X.509's Common Name field to write DNS names in, but this field is just defined as arbitrary human readable text. "news.ycombinator.com" is text, but so is "News·YCombinator,coM " and only one of those is a DNS name. So, when the IETF standardised PKIX it designed a dedicated schema for the various types of Internet names to put into certificates, Subject Alternative Names SANs. Unlike the Common Name a SAN dnsName literally can't be anything but a DNS name using A-labels ("punycode"). So the opportunity for confusion is removed. Since it doesn't need to address universal human text it doesn't need to support weird encodings or anything else. When PKIX was standardised the existing abuse of Common Name was grandfathered in. PKIX says all certs should list one or more SANs but they may continue to have a DNS name in the Common Name too. The Baseline Requirements, years later, explicitly tell CAs to only use a Common Name which matches one of the SANs they've also baked into the certificate, if there are no SANs they're doing it wrong. Alas, as so often, commercial priorities beat security and so even last decade it was common to find people trying to get away without SANs. However the roll out of Certificate Transparency allowed us to have a clear view, without waiting for incident reports from affected users, of non-compliant certificates still being issued, so we could address it as it happened. A few years ago Firefox and Chrome (and Safari I think?) were able to remove their code for trying to process the human readable Common Name as if it might be important, and so if anybody were to issue such a certificate with no SANs today it wouldn't "work" in popular browsers.

by ce4 7y ago

chrishas35 7y ago

There were no end-user visible certificate errors during the outage, so I suspect it was an internal/backend cert.

notimetorelax 7y ago

MS has internal CA, it’s most probably some internal back-end talking to some other internal service.

tialaramex 7y ago

> if it's a SAN certificate All certificates in the Web PKI are obliged to use SAN (Subject Alternative Name). Although it is often mistaken for some sort of aliasing feature, SAN is the Internet's agreed alternative way to name things. X.509 is intended as part of the X.500 directory system, a global directory system which obviously was never actually built, and so its built-in name scheme doesn't resemble anything that actually exists. When Netscape invented SSL back in the 1990s they hijacked X.509's Common Name field to write DNS names in, but this field is just defined as arbitrary human readable text. "news.ycombinator.com" is text, but so is "News·YCombinator,coM " and only one of those is a DNS name. So, when the IETF standardised PKIX it designed a dedicated schema for the various types of Internet names to put into certificates, Subject Alternative Names SANs. Unlike the Common Name a SAN dnsName literally can't be anything but a DNS name using A-labels ("punycode"). So the opportunity for confusion is removed. Since it doesn't need to address universal human text it doesn't need to support weird encodings or anything else. When PKIX was standardised the existing abuse of Common Name was grandfathered in. PKIX says all certs should list one or more SANs but they may continue to have a DNS name in the Common Name too. The Baseline Requirements, years later, explicitly tell CAs to only use a Common Name which matches one of the SANs they've also baked into the certificate, if there are no SANs they're doing it wrong. Alas, as so often, commercial priorities beat security and so even last decade it was common to find people trying to get away without SANs. However the roll out of Certificate Transparency allowed us to have a clear view, without waiting for incident reports from affected users, of non-compliant certificates still being issued, so we could address it as it happened. A few years ago Firefox and Chrome (and Safari I think?) were able to remove their code for trying to process the human readable Common Name as if it might be important, and so if anybody were to issue such a certificate with no SANs today it wouldn't "work" in popular browsers.