When migrating servers to new infrastructure with different IP blocks, certificate management depends on your certificate's binding configuration. The critical factors are:

• Certificate type (DV/OV/EV)
• Subject Alternative Names (SANs) configuration
• Whether the certificate is IP-bound or domain-bound

For most modern certificates, the IP address change won't require reissuance if:

1. The certificate is bound to domain names (not IP addresses)
2. DNS records are properly updated to point to the new IPs
3. The certificate's Common Name (CN) and SANs remain unchanged

Follow this pre-migration checklist:

# Verify certificate binding type
openssl x509 -in certificate.crt -text -noout | grep -E "Subject Alternative Name|DNS:"

# Export current certificate (IIS example)
$cert = Get-ChildItem -Path Cert:\LocalMachine\My -DnsName "yourdomain.com"
Export-PfxCertificate -Cert $cert -FilePath "C:\migration\cert.pfx" -Password (ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText)

After DNS propagation, test with:

# OpenSSL verification
openssl s_client -connect newserver.com:443 -servername newserver.com | openssl x509 -noout -text

# PowerShell test
Test-NetConnection -ComputerName newserver.com -Port 443

You'll need new certificates if:

• Certificates are explicitly bound to old IPs (rare in modern setups)
• Changing domain names in CN/SAN fields
• Certificate includes IP SANs that won't match new infrastructure

For large-scale migrations, consider:

# ACME client for Let's Encrypt (pre-issue for new IPs)
certbot certonly --manual --preferred-challenges dns -d *.example.com

# Certificate store management script
$newCert = Import-PfxCertificate -FilePath C:\new\cert.pfx -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString -String "pass" -Force -AsPlainText)
$binding = New-WebBinding -Name "Default Web Site" -Protocol "https" -Port 443
$binding.AddSslCertificate($newCert.GetCertHashString(), "My")

html

When migrating servers to a new facility with different IP blocks, many administrators worry about SSL certificate validity. The good news: standard SSL/TLS certificates bind to domain names, not IP addresses. As long as your domain (e.g., example.com) remains unchanged, no reissuance is typically required.

To ensure smooth transition:

• Verify your certificate type: Domain Validation (DV), Organization Validation (OV), or Extended Validation (EV)
• Check certificate details using OpenSSL: openssl x509 -text -noout -in certificate.crt
• Confirm no IP-specific SANs (Subject Alternative Names) exist

Exceptions where reissuance might be necessary:

# Example of IP-bound certificate (rare case)
openssl req -newkey rsa:2048 -nodes -keyout domain.key \
-subj "/CN=192.168.1.100" -addext "subjectAltName=IP:192.168.1.100"

For IIS servers specifically:

1. Export current certificate: certmgr.msc → Export with private key
2. Prepare PowerShell script for import:

   # Import certificate on new server
   $cert = Import-PfxCertificate -FilePath C:\path\to\cert.pfx \
   -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString -String "yourPassword" -AsPlainText -Force)

3. Configure IIS binding programmatically:

   New-WebBinding -Name "Default Web Site" -IPAddress "*" -Port 443 -Protocol "https"

Ensure intermediate certificates are properly installed on the new server. Verify chain completion:

openssl verify -CAfile fullchain.pem yourdomain.crt

For zero-downtime migrations, consider Let's Encrypt with DNS challenges:

certbot certonly --dns-route53 -d example.com \
--preferred-challenges dns-01 --non-interactive

Essential checks:

• Test with SSL Labs: https://www.ssllabs.com/ssltest/
• Verify OCSP stapling: openssl s_client -connect example.com:443 -status
• Check HTTP/2 compatibility if applicable

Q: What if we're changing domains during migration?
A: You'll need new certificates containing the new domain in CN or SAN fields.

Q: How to handle load balancers with IP restrictions?
A: Consider certificate sharing techniques or SAN certificates covering all endpoints.