Loading...
 

Microsoft Certificate Authority



Some general documentation and discussion on our internal Microsoft Certificate Authority.

Migrating from SHA1 to SHA2

How to import third-party certification authority (CA) certificates into the Enterprise NTAuth store

  • See this article for more detail (http://support.microsoft.com/kb/295663)

Windows Security Alert appears when connecting to a wireless network on a workgroup machine

  • See this article for more detail (http://support.microsoft.com/kb/2518158)
  • This is the command that can be used to import a certificate into the NTAUTH certificate store
    certutil -enterprise -addstore NTAuth CA_CertFilename.cer

Enable 512 bit Private Key

  • Seems like we keep having to set this as Microsoft keeps releasing patches that block our 512 bit CA certificate. This will lower the minimum private key length back to 512
    certutil -setreg chain\minRSAPubKeyBitLength 512

Subject and Issuer

  • If you think of certificates in a chain or a hierarchy the Subject and Issuer of the certificate relate to each other in that the Subject would describe whatever certificate in the chain you are looking at and the Issuer would describe the certificate above in the chain. All the way up to the Root certificate in which case the Subject and the Issuer are both the same because the Root certificate is at the top of the chain. For Example:
    • RootCert
      • RootCertIssuer = RootCertifiicate
      • RootCertSubject = RootCertificate
        • IntermediateCert
          • IntermediateCertIssuer = RootCertificate
          • IntermediateCertSubject = IntermediateCert
            • MyServerCert
              • MyServerCertIssuer = IntermeidateCert
              • MyServerCertSubject = MyServerCert
  • But what if you have an internal CA and have perhaps renewed your CA certificate in order to change the public key length. The Subject and Issuer will be the same as the previous certificate.
    • Here is where the Subject Key Identifier and Authority Key Identifier attributes come in. They are V3 extensions to the certificate which any modern certificate should have, but some older V1/V2 certificates may not. These identifiers are some form of a hash of the certificate raw data and will be unique per certificate. You can equate the Subject Key Identifier to the Subject and the Authority Key Identifier to the Issuer in the example above. Using these values your can determine what the actual Issuer certificate is if you multiple CA certificates with the same Subject/Issuer
    • One addtional not on the V3 extension attributes, they are ASN Encoded Data objects. So if you are trying to read these attributes programatically you will need to use the System.Security.Cryptography.ASNEncodedData class.

Powershell PKI Module

  • There is a third party powershell PKI module that can be used to perform CA related tasks, downloadable from this link

Subject Alternative Names

We all know that in order to have a successful SSL handshake and subsequent connection the hostname that you are connecting to must match the "CN" of the SSL certificate being presented by the server. So what if you need to connect to a server via a CNAME, which ultimately resolves to another hostname. For example, try to connect to server1.somedomain.com which actually points to server2.somedomain.com and that is the server certifcate being presented, however your client thinks it connected to server1.somedomain.com and since the certificate being presented isn't for server1.somedomain.com the handshake fails. If you were capturing the conversation you would likely see and "Encrypted Alert (21)" message in one of the packets. This issue first appeared on our Linux servers using AD authentication (which use TLS or LDAP over SSL) when we started refreshing our domain controllers. We would retire one and leave a CNAME pointing to the new one......So, for the purposes of this documentation the discussion is targeted toward domain controllers but most of the information is applicable to other scenarios.

So.....how to get around this?......Subject Alternative Names are the answer. They are extension attributes where you specify multiple DNS Names for the certificate. You can refer to Microsoft KB931351 for more information. Before we outline how to create the cert with subject alternative names in our environment there are a few caveats that I should mention:
  1. When generating the new cert request the CN of the cert should be the FQDN of the domain controller
  2. When adding the subject alternative names, the FQDN of the domain controller should also be one of the subject alternative names
  3. By following the procedure below the new cert will automatically be installed in the "Computer > Personal" certificate store, if for some reason you are installing the cert manually, that is where you should install it.
  4. Multiple certs in the "Computer > Personal" certificate store is no good. When it comes to Server Authentication the server seems to default to presenting the certificate that is created automatically when joining the domain. So in order to present the certificate that you have created with the subject alternative names you must delete the existing certificate and only your new subject alternative name cert should exist in the "Computer > Personal" store. The other caveat to be aware of here is "AutoEnrollment", if "AutoEnrollment" is on when the server reboots the default domain certificate will be added back into the "Computer > Personal" store. I have found that you can disable "AutoEnrollment" via the "Local" security policy if you only need to do this on a small subset of domain controllers.
  5. When generating the cert request you can use any template that contains the "Server Authentication" extension ("Template > Properties > Extensions > Applications Policies") however since we are dealing with domain controllers, I created a new template called "Domain Controller Authentication Custom" that was duplicated from the built in "Domain Controller Authentication" template that is used when creating the default domain certificate.

Here is a quick outline of how to generate and install the cert with subject alternative names:
  1. Log on to the domain controller that you will be generating the certificate for and open the Certificates MMC, adding the local computer store to the MMC
  2. Navigate to the "Personal" certificate store in the MMC
    1. You should see a certificate issued to the FQDN of the domain controller you are connected to
    2. First, export that certificate, just in case. You won't be able to export the private key, don't worry about that.
    3. Then delete that certificate
  3. Open a browser and navigate to http://<your_CA>/certsrv
    1. Click "Request a certificate"
    2. Click "Advanced certificate request"
    3. Click "Create and submit a request to this CA"
    4. Under "Certificate Temaplate", select "Domain Controller Authentication Custom"
    5. Fill in the following fields:
      1. Name = FQDN of the domain controller
      2. E-Mail = some_email at domain.com
      3. Company = My Company
      4. Department = My Department
      5. City = San Diego
      6. State = CA
      7. Country = US
    6. Under "Key Options"
      1. Check "Store certificate in the local computer certificate store"
    7. Under "Additional Options"
      1. In the "Attributes" text box, add your subject alternative names in the following format
        san:dns=somehostname1.somedomain.com&dns=somehostname2.somedomain.com&dns=somehostname3.somedomain.com
    8. Click "Submit"
    9. Click "Install this certificate" (this will automatically install the new cert in the Computer > Personal certificate store)
  4. Verify that the new certificate was added to the Computer > Personal certificate store
  5. Disable "AutoEnrollment" if necessary
  6. Reboot the domain controller and test
Show php error messages