Microsoft SSL, WTF?

Recently my coworkers have been trying to get office365 working through our various organisation-protecting SSL inspection layers. Everything(ish) worked straight up, but they ran into a problem with activation - due to a very strange certificate on the public-facing activation API service.

The certificates as presented by yaleman.org (Yes, OK, I send the root too, because reasons):

$ echo "GET /\n\n " | openssl s_client -connect yaleman.org:443 -showcerts | egrep "(Certificate chain|s:|i:)"

Certificate chain
0 s:/OU=GT23544099/OU=See www.rapidssl.com/resources/cps (c)15/OU=Domain Control  Validated - RapidSSL(R)/CN=www.yaleman.org
  i:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
1 s:/C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3
  i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
  i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

Fairly normal, signed cert for the domain with a single CN.

OpenSSL x509 on the main cert, you get (some fields omitted):

$ openssl x509 -text -in certfile.pem

Certificate:
Data:
    Version: 3 (0x2)
    Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=GeoTrust Inc., CN=RapidSSL SHA256 CA - G3
    Validity
        Not Before: Sep 30 23:00:22 2015 GMT
        Not After : Oct  2 08:12:27 2018 GMT
    Subject: OU=GT23544099, OU=See www.rapidssl.com/resources/cps (c)15, OU=Domain Control Validated - RapidSSL(R), CN=www.yaleman.org
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
        RSA Public Key: (2048 bit)
    X509v3 Subject Alternative Name:
        DNS:www.yaleman.org, DNS:yaleman.org

So, basically two subjects, using the Subject Alternative Name field - www.yaleman.org and yaleman.org. The key’s signed SHA2, issued 30/9/15. Let’s try it with this doozy.

$ echo "GET /\n\n " | openssl s_client -connect activation.sls.microsoft.com:443 -showcerts | egrep "(Certificate chain|s:|i:)"

Certificate chain
 0 s:/C=US/ST=WA/L=Redmond/O=Microsoft/OU=WSE/CN=activation-v1.sls.microsoft.com/CN=*.phx.gbl/CN=*.sls.microsoft.com/CN=sls.microsoft.com/CN=*.validation.sls.microsoft.com/CN=validation.sls.microsoft.com/CN=*.activation.sls.microsoft.com/CN=activation.sls.microsoft.com
   i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Secure Server CA 2012
 1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Secure Server CA 2012
   i:/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority

That’s quite the subject.

$ openssl x509 -text -in mscertfile.pem

Certificate:
Data:
    Version: 3 (0x2)
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Secure Server CA 2012
    Validity
        Not Before: Aug 24 17:15:56 2016 GMT
        Not After : Nov 24 17:15:56 2017 GMT
    Subject: C=US, ST=WA, L=Redmond, O=Microsoft, OU=WSE, CN=activation-v1.sls.microsoft.com, CN=*.phx.gbl, CN=*.sls.microsoft.com, CN=sls.microsoft.com, CN=*.validation.sls.microsoft.com, CN=validation.sls.microsoft.com, CN=*.activation.sls.microsoft.com, CN=activation.sls.microsoft.com
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
        RSA Public Key: (2048 bit)

Signed by the Microsoft Root CA, issued mid-2016, expiring late 2017, SHA1 root, SHA2 sign, pretty epic subject, and no SANs.

Let’s first look at the chain. Until recently having a SHA1 cert in the chain wouldn’t be a problem.

A summary from AusCERT’s writeup has this from Mozilla:

From version 41 (Q1 2015), all certificates which are due to expire between 1 January 2016 and 31 December 2016 (inclusive), and which include a SHA1 based signature as part of the certificate chain, will be treated as “secure, but with minor errors”; and sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA1 based signature as part of the certificate chain, will be treated as “affirmatively insecure”. Sub-resources from such domains will be treated as “active mixed content”.

and Chrome’s update in January 2015:

To avoid Google Chrome users receiving “affirmatively insecure” browser warnings, you should replace SSL certificates with expiry dates on or after 1 Jan 2017.

AusCERT’s writeup says Microsoft’s infrastructure shouldn’t even trust it:

To be trusted by Microsoft applications/platforms, then all SHA1 code signing certificates should be replaced before 1 January 2016. Digital signatures created from SHA-1 code signing certificates that were timestamped before 1 January 2016 will continue to be trusted on Windows platforms

But subsequent research shows… this may not be the case. Bets on them rolling it back when they realised their own systems were a bit special?