Quickie post – I’ve ran into a handful of servers since SBS2008 that have their Sites certificate expired and this results in a handful of event log messages and other annoyances. It a customer actually uses the Sharepoint service built-in, obviously the site won’t work properly using HTTPS because … well, the certificate is expired.
Reissuing this is pretty easy using the following steps:
- Open the IIS Manager on the SBS Server
- Click on the server name in the left-hand side tree (see image @ #4)
- Double-click SSL Certificates, which opens that section
- Click New Domain Certificate as shown:
- Enter information on the certificate noting that the Common Name should be Sites:
- On the next screen, select the Domain’s certificate authority and enter a friendly name:
Note: To my knowledge, all SBS services come with AD Certificate Services installed, which is the basis for this whole article
- The certificate is now available to IIS. Review your IIS Site bindings and move any sites using the old Sites certificate to the one you just creased.
- Don’t forget to delete the old Sites certificate off the machine or you’ll get warnings in your Application log about it being expired.
For whatever reason, some Sonicwalls will not communicate with some Domain Controllers by simply selecting “Use TLS”. I’ve had some work just fine with this (and using the StartTLS verb), while everyone once in a while I see errors like “LDAP Communication Error” or “Error initializing SSL/TLS, data 0, v1db1:”.
I’m sure if I had more time I’d know the root cause, but here’s the fix.
- On the Server, install the Active Directory Certificate Authority role and just the IIS Management Console (no need for the IIS service itself).
- On a typical DC the defaults for the AD CA setup are fine – store the authority in AD.
- Again, just install the IIS Console – no need to install IIS and add attack vectors!
- Open the Certificates console by opening MMC.EXE, going to File -> Add/Remove Snapin and selecting Certificates. You’ll want the Local Machine’s Computer store.
- Expand Trusted Root CAs and export the newly created CA certificate for your domain.
- Right-click the Certificate and Export.
- Save to a file on the desktop, etc – use the .P7B format to make the Sonicwall happy
- I selected the “Include all Certificates in Chain” option.
- Open the IIS Console and click the server name. There will be only one or two options, one will be for Server Certificates. Double-click that to open.
- Click the Create Domain Certificate link on the right. Enter information for a Sonicwall-specific certificate. Select Next and select the domain’s certificate authority.
- Once created, go back into the Certificates console and right-click the certificate, exporting the certificate with the private key. You’ll need to set a password to protect this key (it’s temporary since you’ll want to delete this file at the end of this process)
- You now have the CA Certificate and a signed certificate for the Sonicwall using that CA.
- Log into the Sonicwall. Go to System -> Certificates.
- Click the Import button, select the option to import a CA. Select the file created above and import the CA.
- Click the Import button again. Select the option to import a certificate. Enter the password used above to protect it, as well as a “Friendly Name” and the certificate file itself.
- Confirm both the CA and the certificate show up in the Sonicwall’s page.
Important! Make sure the certificate shows a Validated status of Yes – otherwise it won’t be selectable in the next steps.
- Go to Users -> Settings. Click the Configure LDAP button. You’ll want to use Port 636, and you’ll want to select the Use TLS (SSL) checkbox. Select the newly imported certificate.
- Click Apply to save your changes and then check that you can still authenticate using LDAP.
- If you have issues, you might want to check your DC’s GPO/Local GPO for LDAP signing.