Tag Archives: CA

What’s in a certificate chain and why?

Have you ever wondered why your web server certificate has a “chain” of other certificates associated with it?

The main reason is so that browsers can tell if your certificate was issued by a CA that has been verified to meet the security, policy and operational practices that all CAs are mandated to meet. That certificate at the top of the chain is commonly called the “root”. Its signature on a certificate below it indicates that the CA operating the root believes that practices of the CA below it meets that same high bar.

But why not issue directly off of the “root” certificates? There are a few reasons; the main one is to prevent key compromise. To get a better understanding, it’s useful to know that the private keys associated with the “root” are kept in an offline cryptographic appliance located in a safe, which is located in a vault in a physically secured facility.
These keys are only periodically brought out to ensure the associated cryptographic appliance is still functioning, to issue any associated operational certificates (for example an OCSP responder certificate) that may be needed, and to sign fresh Certificate Revocation Lists (CRLs). This means that for an attacker to gain access to these keys, they would need to gain physical access to this cryptographic appliance as well as the cryptographic tokens and corresponding secrets that are used to authenticate the device.

CAs do this because keeping keys offline is a great way to reduce the risk of a compromised key, but it’s a poor way to offer a highly available and performant service, so the concept of an Issuing CA (ICA) was introduced. This concept also enabled the “root” to respond to CA key compromise events by revoking a CA certificate that should no longer be trusted. This also enables delegation of control, limiting those who can influence a given ICA to sign something.

Another way CAs solve the “online CA” problem is to use what is commonly referred to as a Policy Certificate Authority (PCA). This model allows a CA to segment operational practices more granularly. For example, maybe the CA is audited to be in compliance with a specific set of government standards so the ICAs associated with those practices would be signed by the corresponding PCA. This not only allows segmentation of policy and procedures, but it also enables separation of usage scenarios. For example, one PCA may only allow issuance of certificates for secure mail while the other PCA may allow issuance of SSL certificates. These PCAs are also very commonly operated as offline entities and have ICAs right underneath them.

While the above two models represent the most common ways a PKI might be segmented, they are not the only two. For example, the operational practices required to be a publicly trusted CA are far stricter than what a typical data center might employ. For this reason, it’s very common for CAs to manage PKIs for other organizations within their facilities.

CAs may also “roll” ICAs as a means to manage CRL size. For example, if a given CA has had to revoke many certificates during its lifespan, it may decide to manage the size of CRLs – it would be appropriate to create a new ICA and take the previous one out of service so that future CRLs can still be downloaded quickly by clients. When this happens both CA certificates may be valid for an overlapping time, but only the more recent one is actively in use.

Long story short, some counts on the number of Certificate Authorities that exist on the internet can be deceiving. One of the easiest ways to see this is to look at a CA called DFN-Verein. They are an educational PKI that manages all of the CAs in their PKI in the same facilities, using the same practices, but for security reasons they create separate ICAs for each organization in their network.

Simply put, the count of CAs in a PKI is not a good way to assess the number of entities issuing certificates in the PKI ecosystem. What you really want to count is how many facilities manage publicly trusted certificates. The problem is that it is too difficult to count – what you can do, however, is count the number of organizations associated with ownership of each “root”. Thankfully Microsoft makes this fairly easy. In March, I did a post on my blog showing a breakdown of the ownership. Unfortunately, this approach does not give you a count of operational facilities that are used for the subordinate CAs, but it’s quite likely that given the operational requirements and costs associated with maintaining them that these two numbers are relatively close.

So what would I like for you to take away from this post? I suppose there are two key points:

  • A public CA using several Certificate Authorities under their direct control is actually a good thing as it indicates they are managing the risk of operating their services and planning for migrations to new algorithms and keys as appropriate.
  • Counting the number of “roots” and “subordinate CAs” found by crawling the web does not actually represent the number of organizations that can act as publicly trusted certificate authorities.

That is not to say the efforts to crawl the web to understand how PKI is deployed and used is not valuable, it is – quite valuable. These projects are an important way to keep an eye on the practices that are actually used in the management of Public PKI.

Additionally, efforts to support Least Privilege designs in PKI and adopt means to actively monitor certificate issuance, such as Certificate Transparency, all represent positive moves to help us better understand what is actually out there.

Government CAs in the Microsoft Root Program

Microsoft was the first Root program in a browser to have an open and transparent process for becoming a CA as well as the first to have public policy, audit and technical requirements that CAs must comply with.

Today while the other browsers have joined on and even raised the bar significantly Microsoft continues to operate their root program in an open and clear way.

One example of this is the list they publish of the companies who meet their requirements; you can see this list here.

There are a number of interesting things we can gleam from this list; one of them is how many governments have their own certificate authorities.

For example as of March 11, 2011 we know that there are a total of 46 government owned and operated “Root Certificates” in the Microsoft Root Program, these include:

Current CA Owner Country Thumbprint
Government of Austria, Austria Telekom-Control Commission Austria e7 07 15 f6 f7 28 36 5b 51 90 e2 71 de e4 c6 5e be ea ca f3
Government of Brazil, Autoridade Certificadora Raiz Brasileira Brazil 8e fd ca bc 93 e6 1e 92 5d 4d 1d ed 18 1a 43 20 a4 67 a1 39
Government of Brazil, Instituto Nacional de Tecnologia da Informação (ITI) Brazil ‎70 5d 2b 45 65 c7 04 7a 54 06 94 a7 9a f7 ab b8 42 bd c1 61
Government of Finland, Population Register Centre Finland fa a7 d9 fb 31 b7 46 f2 00 a8 5e 65 79 76 13 d8 16 e0 63 b5
Government of France France 60 d6 89 74 b5 c2 65 9e 8a 0f c1 88 7c 88 d2 46 69 1b 18 2c
Government of Hong Kong (SAR), Hongkong Post Hong Kong (SAR) d6 da a8 20 8d 09 d2 15 4d 24 b5 2f cb 34 6e b2 58 b2 8a 58
Government of Hong Kong (SAR), Hongkong Post Hong Kong (SAR) e0 92 5e 18 c7 76 5e 22 da bd 94 27 52 9d a6 af 4e 06 64 28
Government of India, Ministry of Communications & Information Technology, Controller of Certifying Authorities (CCA) India 97 22 6a ae 4a 7a 64 a5 9b d1 67 87 f2 7f 84 1c 0a 00 1f d0
Government of Japan, Ministry of Internal Affairs and Communications Japan 96 83 38 f1 13 e3 6a 7b ab dd 08 f7 77 63 91 a6 87 36 58 2e
Government of Japan, Ministry of Internal Affairs and Communications Japan ‎7f 8a b0 cf d0 51 87 6a 66 f3 36 0f 47 c8 8d 8c d3 35 fc 74
Government of Korea, Korea Information Security Agency (KISA) South Korea 5f 4e 1f cf 31 b7 91 3b 85 0b 54 f6 e5 ff 50 1a 2b 6f c6 cf
Government of Korea, Korea Information Security Agency (KISA) South Korea 02 72 68 29 3e 5f 5d 17 aa a4 b3 c3 e6 36 1e 1f 92 57 5e aa
Government of Korea, Korea Information Security Agency (KISA) South Korea f5 c2 7c f5 ff f3 02 9a cf 1a 1a 4b ec 7e e1 96 4c 77 d7 84
Government of Korea, Ministry of Government Administration and Home Affairs (MOGAHA) South Korea 63 4c 3b 02 30 cf 1b 78 b4 56 9f ec f2 c0 4a 86 52 ef ef 0e
Government of Korea, Ministry of Government Administration and Home Affairs (MOGAHA) South Korea 20 cb 59 4f b4 ed d8 95 76 3f d5 25 4e 95 9a 66 74 c6 ee b2
Government of Latvia, Latvian Post Latvia 08 64 18 e9 06 ce e8 9c 23 53 b6 e2 7f bd 9e 74 39 f7 63 16
Government of Latvia, Latvian State Radio & Television Centre (LVRTC) Latvia c9 32 1d e6 b5 a8 26 66 cf 69 71 a1 8a 56 f2 d3 a8 67 56 02
Government of Lithuania, Registru Centras Lithuania 97 1d 34 86 fc 1e 8e 63 15 f7 c6 f2 e1 29 67 c7 24 34 22 14
Government of Macao, Macao Post Macao SAR ‎89 c3 2e 6b 52 4e 4d 65 38 8b 9e ce dc 63 71 34 ed 41 93 a3
Government of Mexico, Autoridad Certificadora Raiz de la Secretaria de Economia Mexico 34 d4 99 42 6f 9f c2 bb 27 b0 75 ba b6 82 aa e5 ef fc ba 74
Government of Portugal, Sistema de Certificação Electrónica do Estado (SCEE) / Electronic Certification System of the State Portugal ‎39 13 85 3e 45 c4 39 a2 da 71 8c df b6 f3 e0 33 e0 4f ee 71
Government of Serbia, PTT saobraćaja „Srbija” (Serbian Post) Serbia d6 bf 79 94 f4 2b e5 fa 29 da 0b d7 58 7b 59 1f 47 a4 4f 22
Government of Slovenia, Posta Slovenije (POSTArCA) Slovenia ‎b1 ea c3 e5 b8 24 76 e9 d5 0b 1e c6 7d 2c c1 1e 12 e0 b4 91
Government of Slovenia, Slovenian General Certification Authority (SIGEN-CA) Slovenia 3e 42 a1 87 06 bd 0c 9c cf 59 47 50 d2 e4 d6 ab 00 48 fd c4
Government of Slovenia, Slovenian Governmental Certification Authority (SIGOV-CA) Slovenia 7f b9 e2 c9 95 c9 7a 93 9f 9e 81 a0 7a ea 9b 4d 70 46 34 96
Government of Spain (CAV), Izenpe S.A. Spain 4a 3f 8d 6b dc 0e 1e cf cd 72 e3 77 de f2 d7 ff 92 c1 9b c7
Government of Spain (CAV), Izenpe S.A. Spain ‎30 77 9e 93 15 02 2e 94 85 6a 3f f8 bc f8 15 b0 82 f9 ae fd
Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV) Spain a0 73 e5 c5 bd 43 61 0d 86 4c 21 13 0a 85 58 57 cc 9c ea 46
Government of Spain, Dirección General de la Policía – Ministerio del Interior – España. Spain b3 8f ec ec 0b 14 8a a6 86 c3 d0 0f 01 ec c8 84 8e 80 85 eb
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Spain 43 f9 b1 10 d5 ba fd 48 22 52 31 b0 d0 08 2b 37 2f ef 9a 54
Government of Spain, Fábrica Nacional de Moneda y Timbre (FNMT) Spain b8 65 13 0b ed ca 38 d2 7f 69 92 94 20 77 0b ed 86 ef bc 10
Government of Sweden, Inera AB (SITHS-Secure IT within Health care Service) Sweden 16 d8 66 35 af 13 41 cd 34 79 94 45 eb 60 3e 27 37 02 96 5d
Government of Switzerland, Bundesamt für Informatik und Telekommunikation (BIT) Switzerland ‎6b 81 44 6a 5c dd f4 74 a0 f8 00 ff be 69 fd 0d b6 28 75 16
Government of Switzerland, Bundesamt für Informatik und Telekommunikation (BIT) Switzerland ‎25 3f 77 5b 0e 77 97 ab 64 5f 15 91 55 97 c3 9e 26 36 31 d1
Government of Taiwan, Government Root Certification Authority (GRCA) Taiwan ROC f4 8b 11 bf de ab be 94 54 20 71 e6 41 de 6b be 88 2b 40 b9
Government of The Netherlands, PKIoverheid The Netherlands 10 1d fa 3f d5 0b cb bb 9b b5 60 0c 19 55 a4 1a f4 73 3a 04
Government of The Netherlands, PKIoverheid The Netherlands 59 af 82 79 91 86 c7 b4 75 07 cb cf 03 57 46 eb 04 dd b7 16
Government of the United States of America, Federal PKI USA 76 b7 60 96 dd 14 56 29 ac 75 85 d3 70 63 c1 bc 47 86 1c 8b
Government of the United States of America, Federal PKI USA cb 44 a0 97 85 7c 45 fa 18 7e d9 52 08 6c b9 84 1f 2d 51 b5
Government of the United States of America, Federal PKI USA ‎90 5f 94 2f d9 f2 8f 67 9b 37 81 80 fd 4f 84 63 47 f6 45 c1
Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA) Tunisia 30 70 f8 83 3e 4a a6 80 3e 09 a6 46 ae 3f 7d 8a e1 fd 16 54
Government of Tunisia, Agence National de Certification Electronique / National Digital Certification Agency (ANCE/NDCA) Tunisia d9 04 08 0a 49 29 c8 38 e9 f1 85 ec f7 a2 2d ef 99 34 24 07
Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM) Turkey 1b 4b 39 61 26 27 6b 64 91 a2 68 6d d7 02 43 21 2d 1f 1d 96
Government of Uruguay, Correo Uruguayo Uruguay f9 dd 19 26 6b 20 43 f1 fe 4b 3d cb 01 90 af f1 1f 31 a6 9d
Government of Venezuela, Superintendencia de Servicios de Certificación Electrónica (SUSCERTE) Venezuela ‎dd 83 c5 19 d4 34 81 fa d4 c2 2c 03 d7 02 fe 9f 3b 22 f5 17
Government of Venezuela, Superintendencia de Servicios de Certificación Electrónica (SUSCERTE) Venezuela ‎39 8e be 9c 0f 46 c0 79 c3 c7 af e0 7a 2f dd 9f ae 5f 8a 5c


With a closer look we see that these 46 certificates are operated by 33 different agencies in 26 countries.


Wikipedia tells us there are 207 governments and now we know apparently 14% of them operate their own globally trusted root.


Though I love to travel and I consider myself a citizen of the world I have never needed to communicate with any of these governments using their private PKIs so I personally have marked them as “revoked” in CryptoAPI, I also manage which of the commercial root CAs I trust manually.

There are some other interesting observations we can gleam from the Root Program membership also, I will do more posts on these later.

A look at the new Windows Update SSL certificates

This morning I noticed a tweet by Mikko about the Windows Update certificate chain looking odd so I decided to take a look myself.

I started with the webserver configuration using SSLLABS, unfortunately it did not fare well:

Looking a little closer we see a few things of interest:

  • SSLLABS is unable to validate the certificate
  • The server is using weak ciphers
  • The server is vulnerable to the BEAST attack
  • The server is not using an Extended Validation  (EV) Certificate
  • The server is supporting SSL 2.0

To understand the specifics here we needed to look a little deeper, the OpenSSL s_client is a great tool for this:

openssl s_client –showcerts -status –connect www.update.microsoft.com:443

Loading ‘screen’ into random state – done


OCSP response: no response sent

depth=1 C = US, ST = Washington, L = Redmond, O = Microsoft Corporation, CN = Microsoft Update Secure Server CA 1

verify error:num=20:unable to get local issuer certificate

verify return:0

Certificate chain

0 s:/C=US/ST=Washington/L=Redmond/O=Microsoft/OU=WUPDS/CN=www.update.microsoft.com

i:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update Secure Server CA 1

1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update Secure Server CA 1

i:/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority

Server certificate




1 s:/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update S

ecure Server CA 1

i:/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority




subject=/C=US/ST=Washington/L=Redmond/O=Microsoft/OU=WUPDS/CN=www.update.microsoft.com issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Update

Secure Server CA 1

No client certificate CA names sent

SSL handshake has read 3403 bytes and written 536 bytes

New, TLSv1/SSLv3, Cipher is AES128-SHA

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE


Protocol  : TLSv1

Cipher    : AES128-SHA

Session-ID: 33240000580DB2DE3D476EDAF84BEF7B357988A66A05249F71F4B7C90AB62986



Master-Key: BD56664815654CA31DF75E7D6C35BD43D03186A2BDA4071CE188DF3AA296B1F9674BE721C90109179749AF2D7F1F6EE5

Key-Arg   : None

PSK identity: None

PSK identity hint: None

Start Time: 1339954151

Timeout   : 300 (sec)

Verify return code: 20 (unable to get local issuer certificate)



With this detail we can also look at the certificates with the Windows Certificate viewer, we just extract the server certificate Base64 and put it into a text file with a .cer extension and open it with Explorer:



From these we see a few additional things:

  • OCSP Stapling is not enabled on the server
  • The issuing CA was created on 5/30/2012 at 8:49pm
  • The issuing CA was issued by the 2001 SHA1 “Microsoft Root Authority”

So with this extra information let’s tackle each of these observations and see what conclusions we come to.


SSLLABS is unable to validate the certificate; there are two possible reasons:

a. The server isn’t including the intermediate certificates (it is) and SSLLABS doesn’t chase intermediates specified in the AIA:IssuerCert extension (doubt it does) or that extension isn’t present (it is).

b. The Root CA isn’t trusted by SSLLABS (which appears to be the case here).

My guess based on this is that Ivan only included the certificates in the “Third-Party Root Certification Authorities” store and did not include those in the “Trusted Root Certification Authorities” which are required for Windows to work.

Basically he never expected these Roots to be used to authenticate a public website.

[2:00 PM 6/18/2012] Ivan has confirmed he currently only checks the Mozilla trusted roots, therefor this root wouldn’t be trusted by SSLLABS.

Microsoft’s decision to use this roots means that any browser that doesn’t use the CryptoAPI certificate validation functions (Safari, Opera, Chrome on non-Windows platforms, Firefox, etc.) will fail to validate this certificate.

This was probably done to allow them to do pinning using the “Microsoft” policy in CertVerifyCertificateChainPolicy.

I believe this was not the right approach since I think it’s probably legitimate to use another browser to download patches.

[2:00 PM 6/18/2012] The assumption in this statement (and it may turn out I am wrong) is that it is possible for someone to reach a path where from a browser they can download patches; its my understanding this is an experience that XP machines using a different browser have when visiting this URL I — I have not verified this.

[3:00 PM 6/18/2012] Harry says that you have not been able to download from these URLs without IE ever, so this would be a non-issue if that is the case.

To address this Microsoft would need to either:

  • Have their PKI operate in accordance with the requirements that other CAs have to meet and be audited and be found to meet the requirements of each of the root programs that are out there.
  • Have two separate URLs and certificate chains one for the website anchored under a publicly trusted CA and another under this private “Product” root. The manifests would be downloaded from the “Product” root backed host and the web experience would be from the “Public” root backed host.
  • Cross certifying the issuing CA “Microsoft Update Secure Server CA 1” under a public CA also (cross certification), for example under their IT root that is publically trusted and include that intermediate in the web server configuration also. Then have a CertVerifyCertificateChainPolicy implementation that checks for that CA instead of the “Product” roots.


The server is using weak ciphers; the server is using several weak ciphers:

I see no reason to support the MD5 based ciphers as I find it hard to believe that there are any clients that can communicate with this site that do not support their SHA1 equivalents.


[2:00 PM 6/18/2012] I have been told I am too critical by calling these MD5 based ciphers as weak in that they are used as HMAC, it is true that when used with a key as is the case with HMAC the current attacks are not relevant. With that said any client that supports these suites will also support their SHA1 counterpart and there is no reason to support the weaker suites that use MD5.


The server is vulnerable to the BEAST attack; and SSLLABS isn’t able to tell if the server is specifying a cipher suite preference, this means it probably is not.

It is the cipher suite ordering issue that is actually resulting in the warning about the BEAST attack though. It is addressed by putting RC4 cipher suites at the top of the cipher suite order list.

[2:00 PM 6/18/2012] It’s been argued the BEAST attack isn’t relevant here because the client is normally not a browser, these pages that are returned do contain JS and there are cases where users visit it via the browser — otherwise there would not be HTML and JS in them. As such the attacker could use the attack to influence you to install malicious content as if it came from Microsoft. Maybe its not a leakage of personal information initially but its an issue.


It is not using an Extended Validation (EV) Certificate; this is an odd one, is an EV certificates necessary when someone is attesting to their own identity? Technically I would argue no, however no one can reasonably expect a user to go and look at a certificate chain and be knowledgeable enough to that this is what is going on.

The only mechanism to communicate the identity to the user in as clear a way is to make the certificate be an EV certificate.

Microsoft really should re-issue this certificate as an EV certificate – if there was ever a case to be sure who you are talking to it would certainly include when you are installing kernel mode drivers.


The server is supporting SSL 2.0; this also has to be an oversight in the servers configuration of SSL 2.0 has been known to have numerous security issues for some time.

They need to disable this weak version of SSL.


OCSP Stapling is not enabled on the server; OCSP stapling allows a webserver to send its own revocations status along with its certificate improving performance, reliability and privacy for revocation checking. According to Netcraft Windows Update is running on IIS 7 which supports it by default.

This means Microsoft is either not allowing these web servers to make outbound connections or they have explicitly disabled this feature (login.live.com has it enabled and working). While it is not a security issue per-se enabling it certainly is a best practice and since it’s on by default it seems they are intentionally not doing it for some reason.


The issuing CA was created on 5/30/2012 at 8:49pm; this isn’t a security issue but it’s interesting that the issuing CA was created four days before the Flame Security advisory. It was a late night for the folks operating the CA.


That’s it for now,



The tale of two (Microsoft) PKIs

As you know I used to work at Microsoft on areas surrounding cryptography, certificates, protocols and other such things.

While I can’t talk about the internal workings of things I can explain the high level roles the two sets of PKIs Microsoft maintains.

The first PKI is the Microsoft “Product Roots”; these are the keys and certificates that are managed with the sole purpose of being used for product scenarios. You can see the names and serial numbers of these CAs here.

The next is the “IT Root”, that is the one folks see associated with a S/MIME email from a Microsoft employee, some of the corporate websites have SSL certificates from this hierarchy and if you were to inspect the badges of an employee you would see a certificate from here that is used for smart card login and other related scenarios.

The “Product Roots” are trusted only by Windows and applications that have either built on the Windows CryptoAPI or simply imported the roots from the Microsoft Root Program.

The “IT Root” is trusted by third-party browsers because it has been cross signed with a public CA, currently that CA is Verizon the certificate is labeled “GTE CyberTrust”.

I hope that helps clarify for people,


MSRC 2718704 and Nested EKU enforcement

There are a number of technical constraints a Certificate Authority can put into place on a subordinate Certificate Authority; the general concept is referred to as Qualified Subordination.

One of the most important ways to constrain a certificate is through by restricting what it can be good for.

The foundation for such a constraint is provided by PKIX in the Extended Key Usage extension (RFC 5280), this extension can be put into a certificate to restrict what it is trusted for – for example a certificate might be OK for SSL Server Authentication but not for S/MIME.

The problem is the RFC provides no practical guidance on how to act when this certificate is encountered in a CA certificate, all it says is:

In general, this extension will appear only in end entity certificates.

One can interpret this to mean that its semantics are the same in issuer or subscriber certificates, this makes sense but isn’t very useful as a CA is not very likely to ever perform “application tasks” like S/MIME or SSL Server authentication with its signing key, so why would you put it in a CA certificate?

Also if you look back at the history this extension was really one of the first that was introduced, it came into existence in a time where PKIs were only one level deep – the absence of guidance on how to handle this could easily be seen as an omission.

Microsoft saw it this way and decided to have their implementation treat this extension as a constraint, in other words if no EKU is present in the chain then the chain is considered good for all usages. But once a single EKU is added into the path nothing bellow it can be considered good for a non-listed EKU.

In Windows applications validate certificates using the CertGetCertificateChain API takes a number of control parameters via the PCERT_CHAIN_PARA structure, one can specify what EKUs they want to make sure a certificate is good for via the RequestedUsage parameter.

This logic (frankly almost all of the certificate validation) is all wrapped into this one call.

So what does this have to do with MSRC 2718704? Well it has reduced the risk of this mess up in a meaningful way I thought I would explain but before I do let me explain that I am not trying to downplay the significance of this issue I am just trying to clarify where the risks are.

As we know now the “licensing solution” deployed for terminal services has put a signing CA that is trusted for Code Signing in ever enterprise that uses the product.   But how is it restricted to just Code Signing, that’s really what this post is about.

Let’s look at the EKUs included in the offending “MS” certificate, in that chain we see:

  • Microsoft Root Authority
    • No EKUs
  • Microsoft Enforced Licensing Intermediate PCA
    • EKUs = Code Signing, Key Pack Licenses, License Server Verification
    • Effective EKUs = Code Signing, Key Pack Licenses, License Server Verification
  • Microsoft Enforced Licensing Certificate Authority CA
    • EKUs = Code Signing, License Server Verification
    • Effective EKUs = Code Signing, License Server Verification
  • Microsoft LSRA PA
    • EKUs = None
    • Effective EKUs = Code Signing, License Server Verification
  • MS
    • EKUs = None
    • Effective EKUs = Code Signing, License Server Verification

You will notice that the “Microsoft LSRA PA” certificate lists no EKUs but the Effective EKUs are listed as “Code Signing” and “License Server Verification”, this is because of the Nested EKU behavior I describe above.

The same thing happens in the end “MS” certificate; even though it has no EKUs listed I can only be used to validate licenses and sign-code because that’s all it’s issuers are entitled to bestow onto its subordinates.

OK so what does all of this mean to you and me? It basically means as long as the application is written using CryptoAPI in the intended way (and all do that I am aware of in this context) those CAs out there cannot be used to issue SSL certificates (or any other usages not listed) that would be “valid”, they can of course sign code as Microsoft which is a larger issue in my book.

Anyway over the years I have proposed in IETF that this same behavior be adopted, it was always rejected as an evil Microsoft conspiracy (I was at Microsoft at the time) it of course was nothing of the sort but in the end I gave up. Recently I have started trying to convince the browsers directly to implement this same behavior as I feel it is beneficial, for example here is a NSS bug tracking the same request, if implemented that would take care of Chrome and Firefox, that still leaves Safari and Opera but it’s a step in the right direction.


Additional Resources


How to mitigate the risk of the DigiNotar *.google.com SSL certificate

Given the recent news relating to DigiNotar issuing a certificate to an entity claiming to represent google that has turned out to be a malicious entity it’s probably most appropriate to cease trusting the DigiNotar root until the specifics of the issue have been identified.

As a practical matter they do little work outside the EU and are a very small player so your experience on the internet is not likely to be diminished as a result of not trusting them anyways.

That begs the question of how to do that? On the surface you might think what you need to do is to remove the DigiNotar root from your root store and in the case of Firefox, Opera that would do it (at least until they next patch and it gets added back in, that is unless they nix it too.).

In the case of IE and Chrome (which uses the Windows trust anchors) this is insufficient, there is a feature called “Automatic Root Update” (http://netsekure.org/2011/04/automatic-ca-root-certificate-updates-on-windows) that maintains the roots for you based on a policy that Microsoft maintains. When its enabled Windows will check with Windows Update as part of certificate validation to see if it should add a root to enable the path to build. You do not have to use this capability but I would not recommend disabling it unless you are a PKI savvy.

If that’s the path you follow, be sure to delete the root certificate from your Computer Accounts Third-Party Certification Authorities store also (if it happens not to be there, don’t fret if it isn’t that just means you have never encountered a certificate from them).

You also might want to check out a couple posts that Nasko has done relating to managing your own certificate store like this one (http://netsekure.org/2010/05/results-after-30-days-of-almost-no-trusted-cas/) and this one (http://netsekure.org/page/2/).

For everyone else all I would recommend is:

  1. Download the DigiNotar Root Certificate (http://www.diginotar.nl/files/Rootcertificaten/DigiNotar%20root%20CA2007.crt)
  2. Run mmc.exe
  3. Add the Certificate Management console
  4. Target it at the Computer Account certificate stores
  5. Add the DigiNotar Root Certificate to the “Untrusted Certificate” store

Now this is a bit more draconian than you may strictly need to but until its clear if it was the root that was compromised, a subordinate or their vetting practices the right thing to do is not to trust any certificates from them.

As I said before this is not likely to have any negative effects on your experience on the web and it will protect you from the attacks this issue represents.

I should note that I am assuming (and you know what they say about assumptions) that this is the only DigiNotar root, trusted by the browsers; I checked a few sources and it seems like that is the case but all of the CA trust programs do a poor job publishing this stuff these days. When I ran the Windows program we maintained a KB with the trusted CAs and their certificates in it, that doesn’t seem to be the case any longer, sigh.

Good luck,


P.S. Nasko has also done a good post on how to manage the root stores on Windows you can find it here (http://netsekure.org/2010/04/how-to-disable-trusted-root-certificates/)

P.P.S. I have verified that for sites that have been pinned Chrome (only Chrome and only Pinned) google will flag these, IMHO this is good but you still need to remove it to be safe in the other cases. (see: http://www.breitbart.com/article.php?id=CNG.f17dd620575edb02954a7f8f0971f63b.4c1&show_article=1)

P.P.P.S. Looks like all 3 major browsers have untrusted DigiNotar