Google Chrome window showing SSL certificates are not valid.

Introduction — Expired Sitecore SSL Certificates

At some point, the self-signed out-of-the-box Sitecore Install Framework (SIF)-generated SSL certificates will expire. If you’re working in a local development environment, this guide shows how to recover quickly and get back up-and-running without battling through hours of certificate errors.

The following method of getting things up-and-running again simplifies the approach of having three certificates (if you’re using xconnect and identity server) and reducing it to a single wildcard certificate. Follow the instructions below to generate a wildcard certificate for your local environment that can be used for all desired Sitecore development work – across multiple installs and versions.

Step 1 — Certificate Generation

The PowerShell script below creates a single wildcard certificate for local development, exports it as a PFX, adds it to the necessary certificate stores, and sets the correct permissions so all Sitecore services can access it without issue.

It will create one certificate in the expectation that it can be used across your environments to replace all expired Sitecore SSL certificates. For this to work the hostnames must all end in *.dev.local (or whichever suffix you wish to use). If yours is different, tweak the script to suit your needs. If your local domains don’t follow this pattern, you can modify the $site variable and re-run the script for each required hostname. Other variables are the expiry date of the certificate, which you can extend into the future. Lastly, the export path, where a copy of the certificate will be saved.

Save the below script as a .ps1 file, update the variables at the top as needed, and run it either in an elevated PowerShell, or in the PowerShell ISE:

# Update custom settings and run as Administrator
$site = "*.dev.local"
$subject = "CN=$site"
$friendlyName = $site
$expiryDate = Get-Date -Year 2030 -Month 1 -Day 1
$certStorePath = "cert:\LocalMachine\My"
$exportPath = "C:\Temp\Certificates"

# Ensure export path exists
if (-not (Test-Path $exportPath)) {
    New-Item -ItemType Directory -Path $exportPath -Force | Out-Null
}

# Create the certificate
$cert = New-SelfSignedCertificate `
    -Subject $subject `
    -DnsName $site `
    -FriendlyName $friendlyName `
    -CertStoreLocation $certStorePath `
    -NotAfter $expiryDate `
    -KeyExportPolicy Exportable `
    -Type SSLServerAuthentication `
    -Provider "Microsoft RSA SChannel Cryptographic Provider"

$thumbprint = $cert.Thumbprint
$pfxPath = Join-Path $exportPath "$thumbprint.pfx"

# Export to PFX
$password = Read-Host -Prompt "Enter password to protect the certificate" -AsSecureString
Export-PfxCertificate -Cert $cert -FilePath $pfxPath -Password $password -Force | Out-Null
Write-Output "PFX exported to: $pfxPath"

# Add to Trusted Root store
$rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store "Root", "LocalMachine"
$rootStore.Open("ReadWrite")
$rootStore.Add($cert)
$rootStore.Close()
Write-Output "Certificate added to Trusted Root Certification Authorities."

# Grant 'Everyone' access to the private key
$privateKey = $cert.PrivateKey
$keyContainer = $privateKey.CspKeyContainerInfo.UniqueKeyContainerName
$keyFile = Join-Path "$env:ProgramData\Microsoft\Crypto\RSA\MachineKeys" $keyContainer

if (Test-Path $keyFile) {
    $acl = Get-Acl $keyFile
    $rule = New-Object System.Security.AccessControl.FileSystemAccessRule("Everyone", "FullControl", "Allow")
    $acl.AddAccessRule($rule)
    Set-Acl $keyFile $acl
    Write-Output "Private key permissions granted to 'Everyone'."
} else {
    Write-Warning "Private key file not found: $keyFile"
}

# Output final message with thumbprint
Write-Output ""
Write-Output "Certificate setup complete. Use the following thumbprint in your configuration files when replacing expired Sitecore SSL certificates."
Write-Output "Thumbprint: $thumbprint"
Write-Host ""
Read-Host "Press Enter to close the window"

What’s a thumbprint?

A thumbprint is a unique hash that identifies a certificate. You’ll need to paste this into config files so Sitecore knows which certificate to use.

You should see something like this if everything ran smoothly, including the newly-generated certificate thumbprint, which you should copy and keep a note of:

Screenshot of PowerShell window after successfully running the script.

The certificate is added to both the Personal (My) and Trusted Root Certification Authorities stores for a good reason. The former is where it’s actively used by services and applications, while the latter ensures that Windows (and everything running on it) actually trusts the certificate in the first place. Without it in the Trusted Root store, you’d still be hit with those recurring “untrusted certificate” warnings.

Why grant access to “Everyone”?

Granting access to “Everyone” on the private key is pragmatic for local development because it sidesteps the permission issues that often pop up when different services (running under different accounts) attempt to access the same key. It’s not something you’d do in production, but it’s acceptable for local development.

You can read more about generating self-signed certificates using Microsoft’s New-SelfSignedCertificate on its module reference page.

Step 2 — Thumbprint Updates

Copy the thumbprint at the end of the PowerShell output. You will need to update any relevant Sitecore configuration files with it when replacing the ones from your expired Sitecore SSL certificates. Make sure to back up any files before modifying them, so you have a reference point if things go wrong (e.g., you miss a closing quote and everything breaks!).

<identity server>\Config\production\Sitecore.IdentityServer.Host.xml
<Sitecore>\App_Config\ConnectionStrings.config
<xconnect>\App_Config\AppSettings.config
<xconnect>\App_Data\jobs\continuous\ProcessingEngine\App_Config\ConnectionStrings.config
<xconnect>\App_Data\jobs\continuous\AutomationEngine\App_Config\ConnectionStrings.config

Step 3 — Update IIS Websites

Finally, update any local websites to use the new certificate (e.g., Sitecore, XConnect, Identity Server). Do this by:

  1. Open IIS and select the website you wish to update.
  2. Click Bindings on the right-hand panel.
  3. Double-click the “https” binding, and change the SSL Certificate field to the new wildcard certificate.
  4. Press OK and Close.
  5. Repeat for any other Sitecore-related websites that used your old certificate.

Before exiting the dialogue, you should see a screen similar to the following:

Screenshot showing certificate bindings in IIS. Fix expired Sitecore SSL certificates.

Run the iisreset command from a PowerShell window or Command Prompt and check that all affected websites and services are running normally.

Step 4 — Restart Windows Services

Click the Start Menu and run services.msc to load the necessary snap-in. Find any Sitecore services (e.g., Sitecore Marketing Automation Engine, Sitecore Processing Engine, Sitecore XConnect Search Indexer), and restart them.

If any of the services fail to stop or restart, find the processes in Task Manager and kill them manually. You can then start the services via the Services snap-in.

Step 5 — Final Checks

Finally, examine the logs for each Sitecore service and ensure that there are no certificate errors. If there are errors, ensure that all thumbprints have been replaced by using Notepad++ or Agent Ransack-type tool to do a global search of the old thumbprint.

Once you’re happy that everything is working normally, you can remove the old certificates by opening the Start Menu and running certlm.msc to open Manage Computer Certificates. Here, you can view the old and new certificates in the Personal and Trusted Root Certification stores.

Screenshot of Manage Local Certificates (certlm.msc) Microsoft console snap-in.

If you don’t see recent updates in this view, press the refresh icon, or close and re-open the snap-in to see the latest changes.

We’re Done!

Hopefully this helps simplify what can sometimes be a really painful and time-consuming process. With a single wildcard certificate, a bit of PowerShell, and a handful of config tweaks, you can replace your expired Sitecore SSL certificates and get your local environment back up-and-running in no time.

Leave a Reply

Your email address will not be published. Required fields are marked *