Lessons Learned: Public Certificate Authorities and Azure Stack Certificates

In my previous blog post yesterday, Using AzsReadinessChecker To Generate Certificate Signing Request for Azure Stack I showed how to use the AzSReadinessChecker tool provided by Microsoft to create a CSR that you could then take to your Public Certificate Authority.  I created a single CSR request that had all my Subject Alternative Names (SAN’s) in a single wildcard certificate.  All was good and I was ready to move on to requesting the certificates with our vendor, a fairly large and well-known one.  It turns out that this vendor doesn’t support multiple SAN’s within a single certificate.  So what does this mean for this project?  The cost of the Public Certs went from about $600.00 to about $6000.00 dollars because now we had to get separate wildcard certs for each endpoint needed.  (I didn’t fully add the cost up but being that a single wildcard cert is about $550.00 dollars times all the certs that I would be requesting I roughly guessed $6000.00)

Why so much?  I will break it down a little.  Now, this is coming from me, someone who rarely deals with certificate request even within an Enterprise CA.    My example is going to include the PaaS required certificates as well.  All this information I am pulling from the Microsoft Documentation located here:

https://docs.microsoft.com/en-us/azure/azure-stack/azure-stack-pki-certs

In 1803 and above there are 9 required certs unless you used ADFS for your identity then you will have an additional 2 more certs required.  If you are planning for PaaS services you will then add an additional 5 more certificates.  As with my case, if you don’t use wildcard certs this will and can be pricey.

 

When I ran the tool on my last blog it would have created a single wildcard for the Azure Stack required certificates.  That included all the SAN’s below in the single wildcard cert:

portal.texas.azurestack.turner.cloud
adminportal.texas.azurestack.turner.cloud
management.texas.azurestack.turner.cloud
adminmanagement.texas.azurestack.turner.cloud
*.blob.texas.azurestack.turner.cloud
*.queue.texas.azurestack.turner.cloud
*.table.texas.azurestack.turner.cloud
*.vault.texas.azurestack.turner.cloud
*.adminvault.texas.azurestack.turner.cloud

***UPDATE***  When you run this tool I had originally posted some incorrect information about the PaaS switch.  I had posted that the tools creates the 3 wildcard certs:

*.appservice.texas.azurestack.turner.cloud
*.scm.appservice.texas.azurestack.turner.cloud
*.sso.appservice.texas.azurestack.turner.cloud

However, the tool does create a single wildcard cert that includes 2 wildcard SAN names within the single certificate.  So you will have a single wildcard cert with a name like *.sso.appservice.texas.azurestack.turner.cloud that when you import that CER to your Public Authority will actually be a wildcard of *.appservice.texas.azurestack.turner.cloud with two wildcard SAN names of *.scm.appservice and *.sso.appservice.  

Also to note that the api.appservice, ftp.appservice, and sso.appservice are standard SSL certificates as well and not wildcard.  This is something Microsoft enforces.

So at the end of the day for the PaaS services you will come out with 2 wildcard certificates, 1 that has 2 wildcard SAN names included, and 3 standard SSL certificates.  

And since I included the -IncludePaaS switch it would have included these SAN names as well:

*.appservice.texas.azurestack.turner.cloud
*.scm.appservice.texas.azurestack.turner.cloud
*.dbadapter.texas.azurestack.turner.cloud
*.sso.appservice.texas.azurestack.turner.cloud
api.appservice.texas.azurestack.turner.cloud
ftp.appservice.texas.azurestack.turner.cloud
sso.appservice.texas.azurestack.turner.cloud

One* wildcard cert to rule them all, correct?  A single charge for $550.00.  However, my vendor doesn’t support multiple SAN names in a single cert.  So instead of a single wildcard cert, I had to request the following certs, each at the price of about $550.00.

***Update***  The following would have changed based off the mistake above.  There is not a way to have a single wildcard certificate for a production multi-node stack if you are installing the PaaS services like App Service.

*.texas.azurestack.turner.cloud with the following SAN names included:

portal.texas.azurestack.turner.cloud
adminportal.texas.azurestack.turner.cloud
management.texas.azurestack.turner.cloud
adminmanagement.texas.azurestack.turner.cloud

*.blob.texas.azurestack.turner.cloud
*.queue.texas.azurestack.turner.cloud
*.table.texas.azurestack.turner.cloud
*.vault.texas.azurestack.turner.cloud
*.adminvault.texas.azurestack.turner.cloud
*.dbadapter.texas.azurestack.turner.cloud

***Update***  The following three wildcards I had listed originally as separate wildcards.  This is not correct.  This should be a single wildcard certificate that supports wild card SAN names.  If you create these at the time using the script the actual name of the certificate would look something like *.sso.appservice but once you import the CER to your Public certificate authority it would be a wildcard for *.appservice. with the two wildcard SAN names like below.

*.appservice.texas.azurestack.turner.cloud

*.scm.appservice.texas.azurestack.turner.cloud
*.sso.appservice.texas.azurestack.turner.cloud

Then the follow 3 are just standard SSL Certs:

api.appservice.texas.azurestack.turner.cloud
ftp.appservice.texas.azurestack.turner.cloud
sso.appservice.texas.azurestack.turner.cloud

So 9 WildCard Certs and 4 Standard Certs and a Wildcard Cert with 2 Wildcard SAN names with an estimated cost of about $6000.00.

* Note:  Reading the Microsoft Documentation they do call out that the following 3 endpoints can’t be wildcards and need to be a single certificate.  However, the tool mentioned in my last blog doesn’t create the CSR that way.  I will double check with the Azure Stack team and update this blog and my last blog.

api.appservice.texas.azurestack.turner.cloud
ftp.appservice.texas.azurestack.turner.cloud
sso.appservice.texas.azurestack.turner.cloud

 

So at the end of the day, I learned a lesson.  Not all public certificate authorities are the same and to make sure you shop around if you can.

Tagged with: , , , , ,
Posted in Azure Stack
2 comments on “Lessons Learned: Public Certificate Authorities and Azure Stack Certificates
  1. Aymen Mami says:

    Hi,
    Thank you for this interessting blog.
    did that certificates actually worked? because according to the Microsoft site, these need to be on the same multi-domain wildcard ssl.

    *.appservice.texas.azurestack.turner.cloud
    *.scm.appservice.texas.azurestack.turner.cloud
    *.sso.appservice.texas.azurestack.turner.cloud

    Thank you

    Like

    • You are correct. I need to edit this to make sure that this specific certificate needs to be a wildcard with wildcard SAN names. It would be a single certificate at this point. So your certificate name would be *.appservice.texas.azurestack.turner.cloud with the 2 wild card SAN names of *scm.appservice and *.sso.appservice. This one could be pricy depending on your Certificate Authority. Also some CA’s don’t even offer wildcard SAN names within a Wildcard Cert.

      Like

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Follow Kristopher Jon Turner on WordPress.com
Categories
Archives
Follow me on Twitter
%d bloggers like this: