How to change the FQDN and related Certs/Settings for the SurePassID Authentication Server

To update SPAS to new DNS names, you must create a new SSL certificate, update IIS bindings, edit configuration files, and adjust DNS or hosts entries.

Changing FQDNs for SurePassID Authentication Server (SPAS)

Steps

A) Create and Install New Certificate

  1. Run the SurePassID PowerShell script (see KB: Creating Self-Signed Certs Self-Signed Cert via PowerShell ).
    • This creates a cert with SANs for all new FQDNs and places it in Trusted Root Certification Authorities.
  2. Open MMCCertificates (Local Computer).
  3. Navigate to Trusted Root Certification Authorities → Certificates, locate the new cert (check Friendly Name).
  4. Copy the cert to Personal → Certificates (Right-click → Copy → Paste).
    • IIS requires the cert in Personal for binding.
  5. Export the cert without the private key (Right-click → All Tasks → Export → choose “No private key”) and save as .cer.
  6. Distribute this .cer file to all client systems (see Section F).
  7. Note the Friendly Name for later IIS binding.

B) Update IIS Bindings

  1. Open IIS ManagerSites → select mfa, api, saml2.
  2. Click Bindings… → Edit https → change Host name to new FQDN.
  3. From SSL certificate dropdown, select the new cert (Friendly Name noted earlier).
  4. Repeat for all three sites.

C) Update Configuration Files

  1. Backup first: Copy these files to a safe location: (paths may vary slightly)
    • C:\Program Files (x86)\SurePassID Corp\SurePassID Authentication Server 2x.x\apiserver\appsettings.json
    • C:\Program Files (x86)\SurePassID Corp\SurePassID Authentication Server 2x.x\mfaserver\web.config
    • C:\Program Files (x86)\SurePassID Corp\SurePassID Authentication Server 2x.x\saml2idp\web.config
  2. Open each file in Notepad or Notepad++ (Run as Administrator).
  3. Replace all old FQDN references (e.g., yourco.com) with new DNS names.
  4. Save changes and close the editor.

Find & Replace Tip

  • Notepad++: Press Ctrl+H → Enter old FQDN in Find what, new FQDN in Replace with → Click Replace All.
  • PowerShell (optional):

(Get-Content "C:\Path\To\appsettings.json") -replace "yourco.com","newco.com" | Set-Content "C:\Path\To\appsettings.json"

Repeat for each config file.


D) Update DNS or Hosts File

  1. Internal DNS: Add A records for new FQDNs → point to server IP.
  2.  Example: Type: A | Name: mfa.newco.com | TTL: 3600 | Target: 10.0.0.5
  3. No DNS? Edit C:\Windows\System32\drivers\etc\hosts to map new FQDNs to server IP.

E) Restart IIS

  1. Run iisreset in Command Prompt (Admin) to apply all changes.

F) Distribute Self-Signed Cert to Clients

Option 1: Non-Domain / Manual

  • Copy the .cer file to each client.
  • On each client:
    1. Open MMCCertificates (Local Computer).
    2. Navigate to Trusted Root Certification Authorities → Certificates.
    3. Right-click → Import → select the .cer file → Finish.

Option 2: Domain Environment via GPO

  • Place the .cer file in a shared location.
  • In Group Policy Management:
    1. Create or edit a GPO linked to target computers.
    2. Navigate to: Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities
    3. Right-click → Import → select the .cer file.
    4. Apply and update GPO (gpupdate /force).

PowerShell Script for Non-Domain Clients

Run as Administrator on each client:

# Import .cer into Trusted Root (Local Machine)
$CertPath = "C:\Temp\SPAS-Root.cer"
$store = New-Object System.Security.Cryptography.X509Certificates.X509Store("Root","LocalMachine")
$store.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite)
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($CertPath)
$store.Add($cert)
$store.Close()

Quick Validation

  • Browse https://mfa.newco.com, https://api.newco.com, https://saml2.newco.com without SSL warnings.
  • Confirm DNS resolves correctly (ping new FQDN).
  • IIS bindings show correct host names and new cert.
  • Config files reflect new FQDNs.
  • Clients trust the cert (no browser warnings).

Common Pitfalls

  • Cert missing SANs → HTTPS fails.
  • Cert not copied to Personal store → IIS cannot bind.
  • Forgetting to update all config files → app errors.
  • Clients not importing cert → trust warnings.