Master & Cmd-R

Add Azure AD Trusted Certificate Authority

Scott Duffey has put together some excellent articles (four parts in total) around setting up Azure AD based CBA, and deploying certificates to mobile devices. It’s worked really well as a guideline for me in setting up certificate based authentication in production environments – however, there’s one scenario that isn’t covered in these articles, and if you’re running a two-tier PKI architecture, you’re going to have some headaches.

Part 2 of the series discusses how to configure your Azure AD as a Certification Authority, but it only shows you how to add your root CA as your trusted certificate authority. If you have a Root CA and an Enterprise or Intermediate CA, you need to upload both certificates into Azure AD. Without this step, your CBA won’t work because your certificate trust chains won’t properly build out. Also, make sure that you publish all required CRLs – if you have a Root CA as well as an Intermediate or Enterprise CA, make sure that both CRLs are publicly available, as you’re going to be setting those URLs using the PowerShell script below.

Connect-AzureAD

# Find existing Certification Authority
     Get-AzureADTrustedCertificateAuthority | FL

# Install Root CA (AuthorityType=0). CRL Distribution Point should be the CRL of the Root CA
     $rootcert=Get-Content -Encoding byte “C:\users\username\Desktop\AzureCA\RootCA.cer”
     $new_rootca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
     $new_rootca.AuthorityType=0
     $new_rootca.TrustedCertificate=$rootcert
     $new_rootca.crlDistributionPoint=“http://domain.com/crl/RootCA.crl”
     New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_rootca

# Install Enterprise CA (AuthorityType=1). CRL Distribution Point should be the CRL of the Enterprise CA
     $entcert=Get-Content -Encoding byte “C:\users\username\Desktop\AzureCA\EntCA.cer”
     $new_entca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
     $new_entca.AuthorityType=1
     $new_entca.TrustedCertificate=$entcert
     $new_entca.crlDistributionPoint=“http://domain.com/crl/cmdrEntCA.crl”
     $new_entca.DeltaCrlDistributionPoint=“http://domain.com/crl/EntCA+.crl”
     New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_entca

# Remove existing Certification Authority – [0] for first cert, [1] for second, etc.
     $c=Get-AzureADTrustedCertificateAuthority
     Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[1]

The important key above is using the AuthorityType=0 for your Root CA, and AuthorityType=1 for your Enterprise CA. I also added a section that will allow you to clear out your certificates and start over if you need to – just use [0] to remove your first cert, and [1] to remove your second.

Hope this helps!


About the Author:


4 Responses to “Add Azure AD Trusted Certificate Authority”

  1. Craig Huff

    May 10, 2018

    This was an excellent post that allowed us to setup CBA for our devices. We have a 2 tiered PKI and was running into issues since the MS document only stated to upload the root.
    Our certs are due to expire in 3 months and we want to migrate with the least amount of downtime. One item that I have not seen anything about is having multiple roots and multiple intermediates. it seems possible but I wanted to make sure that this was allowed and that uploading the new root would not cause any issues with the older one. This would break ~651 devices.
    Thanks

    Reply
    • Jeremy Dahl

      May 10, 2018

      Hi Craig,
      Glad this post helped – it was a very frustrating road until we found the missing pieces!

      I tested uploading additional Root and Intermediate CA certificates, and it allowed me to specify multiples, like you’d expect. I basically had two root CAs and two Enterprise CAs configured as trusted authorities – as far as I know (and I might definitely be wrong here), as long as the cert chains can build out when the lookup happens, it should be fine.

      For instance:
      Cert -> Enterprise 1 -> Root 1 = build success.
      Cert -> Enterprise 2 -> Root 2 = build success.

      Not sure if you’re simply renewing your Enterprise CA, but I figured I’d check them both. I wasn’t able to test actual authentication using the new certs, but you can at least configure them. I’d recommend renewing your certs asap, uploading them, and then testing authentication against both the old and the new, and make sure it’s all working properly long before your certs actually expire.

      Then once those certificates are expired, and you need to remove them, you can use Get-AzureADTrustedCertificateAuthority | FL to identify the TrustedIssuerSki of the certs to remove, and then delete them using something like this:

      Get-AzureADTrustedCertificateAuthority | Where {$_.TrustedIssuerSki -match “B618B233AB95599527FA6E51EFE9D93D0C5307D5”} | Remove-AzureADTrustedCertificateAuthority

      Obviously at this point you’re using the Ski from the command above, but you get my drift…

      Hope this helps – I’m definitely curious to know whether or not the authentication actually works properly, let me know if it does (or doesn’t).

      Reply
      • Craig Huff

        May 14, 2018

        FYI,
        I uploaded the 2 new certs this morning. The person that is testing has come back and says that on his IPAD he is able to use the new certs and the old certs without any issues. So the authentication works perfectly. Thanks for the info..

        Reply
        • Jeremy Dahl

          May 14, 2018

          Great to hear – thanks for letting me know… glad this actually works as expected 🙂

          Reply

Leave a Reply


Jeremy Dahl

Jeremy Dahl - Office 365 Evangelist

Proud member of the team at: