Centralized Certificate Store (CCS) and IIS bindings

Nice description of this feature. I haven't used CCS before and just inherited a site that has this setup. I want to determine which cert is being used by each binding. I don't see anything under the reg hive you mentioned, and can't find a UI or PowerShell command to display this binding info. I shouldn't have to query the store contents and write my own matching logic for explicit vs wildcard certs by pfx filename. Is there a way to report on the chosen binding (without having to visit the site in a browser and see which certificate is provided)? Cheers, Barnaby

Hi Lance,

yes, you have to enable it on each webserver. In our automation process we added this just before the snippet I posted previously:

Write-Host "Enabling Central Cert Provider"
Set-WebCentralCertProvider -UserName "$saUsername" -Password "$saPassword" -PrivateKeyPassword "$certPass"

 where "saUsername" and "saPassword" are our Storage Account credentials (in your case I presume a user with access to the share) and "certPass" is the Certificate Password.
Hope this helps.

Cheers,

Carlo Alberto

Thanks for the write up.  I am wondering if you have to add Centralized Cert support (CCS) to every webserver that uses this in a web farm

today we have ssl termination on the f5 loadbalancers.  We are looking at using the centralized cert store (CCS) and have that setup on 2 webservers in a farm but it seems like for each CCS we have to type in the private key.   If we have 1 share, 30 webservers with CCS, we still have to type in the private key password 30 times?

am I looking at this wrong?

thanks
Lance

Hi,
I am experiencing some issue with CCS and VM automation in an Azure Scaleset.
Basically, I setup a Scaleset which points to two different file shares, one for IIS shared config and one for CCS, and an init powershell script which binds both to IIS.
I also set manually in the shared applicationHost.config file the sslFlags="3" parameter inside each SSL binding.
The script is working properly and when a new VM spins up I can see that both shared config and CSS working and if I check bindings they are properly configured, but if I try to browse a website I get the generic "PR_CONNECT_RESET_ERROR" error.
To solve this I have to manually go to "Edit Site Binding" from IIS Manager and disable and re enable "Use Centralized Certification Store" (as in the picture) and it suddenly start to works.
I see it refreshes the applicationHost.config file because the save date changes, but I compared before and after and no changes were done (so it basically re applies what it already had).

I am really struggling with this, I also tried to perform an IISreset after the execution of the script, but without luck, do you have any idea on how to fix?

EDIT: I post the solution, in case it could be helpful for someone else. The problem was that it is not enough to enable the Centralized SSL and have the correct bindings already inside the ApplicationHost.config and hosts file, each time a new server comes up it is necessary to bind also the HTTP.SYS.
The solution was to add to my init script the update of a fake binding to remap everything:

import-module WebAdministration
Get-Website -Name "Default Web Site" | Get-WebBinding -Protocol "https" -HostHeader "TestSite" | Remove-WebBinding
new-WebBinding -Name "Default Web Site" -Port 443 -SslFlags 3 -Protocol https -HostHeader "TestSite" # this recreate the test binding on IIS
New-Item -Path "IIS:\SslBindings\!443!TestSite" -sslFlags 3 # this binds HTTP.SYS
netsh http show sslcert

now my automation works perfectly, once the bind is created all the existing bindings works with the proper SSL certificate.

Cheers,
Carlo Alberto

BrettM, I bet it has something to do with the server trying to access the share with the WAS process instead of w3svc.  I had a similar issue trying to use a UNC path for shared configuration.  Try giving the computer account access on the share/directory/file resources.  Might need to run it as network service instead of localsystem (which is probably a major security concern).

Hey,

I am trying to demo the usage of Central Certificate Store for our certificate automation. 

I am looking to use AD Integrated Azure Files as the backend, and have setup a Private Link to this share. I then discovered that CCS doesn't like it when the server and username are cross domains, so I have hidden this behind DFS. 

Storage Account:

storage.privatelink.core.windows.net

DFS Root

domain.local\Certificates\

Folder target

CentralStore

\\storage.privatelink.core.windows.net\CentralStore

CCS target

\\domain.local\Certificates\CentralStore

This folder works fine if i browse to it in explorer, so the server itself can access it, and the credentials are good. But CCS with the supplied credentials cannot connect to it. 

Does anyone have any suggestions on how to get this working?

Hi Paul_Heinrich, I think a remote session would speed up the troubleshooting of your server. Do you have a support contract with us? If you do, please create a case: https://support.serviceshub.microsoft.com/supportforbusiness

Otherwise, I would recommend creating a post in our IIS Forum. We have advocates who can follow and contribute to the topic continuously.

https://forums.iis.net/

Hi Nedim,

To answer your question, it looks like no certificate shows up.  My browser (on a laptop) just throws the "PR_CONNECT_RESET_ERROR" which seems to be a generic bad certificate error.  If I try https://www.digicert.com/help/ against the cawl.nau.edu URL I just get a "cannot connect".  If I try payment.mpcer.nau.edu I get a nice display of the full certificate.  Both sites are currently set up with bindings to the centralized certificate store.

Hello Nedim,

I cleared the cache on my browser after restarting IIS on the server.  At this point I have the two sites set to use the centralized store and SNI.  One site payment.mpcer.nau.edu is working.  I can connect and it shows as a secure connection.  However the other site cawl.nau.edu is not working.  I cannot connect to it using SSL, but my non-ssl binding is working (http://cawl.nau.edu)..  I'm using the naming convention suggested in the article where my certificates have the exact same spelling as the domain names (i.e. cawl.nau.edu.pfx) and the certificates in the store look good (names are the same and all of the attributes now show up).  It seems like IIS isn't finding the certificate for cawl.nau.edu..

cheers,  Paul

Hello,

I solved part of the problem.  Once I noticed that in the centralized certificate store the certs had a red x icon, I realized that they had a "incorrect private key" message.  I was able to edit the settings for each certificate adding the private key password I created when I converted the certificates to pfx format. They now show without the red x and include all of the proper attributes and I can view the certificates details by clicking "view" on the right side panel.  So it looks like I have working certificates in the centralized store.  Now if I can get them to bind properly..