A self-signed SSL certificate allows you to enable HTTPS on a web server without purchasing a certificate from a Certificate Authority (CA). While not suitable for public-facing production websites, self-signed certificates are valuable for development, testing, and internal environments. This guide covers multiple methods for creating and installing self-signed certificates in IIS.
When to Use Self-Signed Certificates
Self-signed certificates are appropriate for:
- Development environments: Tests HTTPS functionality locally before deploying with a real certificate.
- Internal applications: Services on a private network where you can install the certificate on all client machines.
- Lab and testing: Staging environments that mirror production configuration.
- API testing: Backend services that need HTTPS but are not publicly accessible.
Self-signed certificates should not be used for:
- Public-facing websites or web applications.
- E-commerce or any site handling sensitive user data in production.
- Any scenario where end users will see browser security warnings.
Method 1: IIS Manager (IIS 7 and Later)
IIS 7 and later versions include a built-in option to create self-signed certificates directly from the management console.
Étapes
- Open IIS Manager (type
inetmgrin the Start menu or Run dialog). - In the left Connections pane, click the server name (the top-level node).
- In the center pane, double-click Server Certificates under the IIS section.
- In the Actions pane on the right, click Create Self-Signed Certificate.
- Enter a friendly name for the certificate (for example,
DevCert-2024). - Select the certificate store: choose Personal for general use or Web Hosting if available.
- Click OK.
The certificate is now created and available in the server’s certificate store. Next, bind it to a website.
Binding the Certificate to a Website
- In IIS Manager, expand Sites and select your website.
- In the Actions pane, click Bindings.
- Click Add.
- Set Type to
https. - Set Port to
443(or your desired port). - In the SSL certificate dropdown, select the self-signed certificate you just created.
- Click OK and close the Bindings dialog.
Test by navigating to https://localhost/ in a browser.
Method 2: SelfSSL Tool (IIS 6.0 Resource Kit)
For older IIS 6.0 installations on Windows Server 2003, the SelfSSL utility from the IIS 6.0 Resource Kit provides a simple command-line approach.
Étapes
- Download and install the IIS 6.0 Resource Kit from the Microsoft Download Center.
- Open a command prompt from Start > Programs > IIS Resources > SelfSSL.
- Run the following command:
selfssl /N:CN=myserver.domain.com /K:2048 /V:365 /S:1 /T
Parameters:
| Parameter | Description |
|---|---|
/N:CN= | The Common Name (hostname) for the certificate |
/K:2048 | Key size in bits |
/V:365 | Validity period in days |
/S:1 | Site ID (1 is typically the Default Web Site) |
/T | Add the certificate to the Trusted Root store on this machine |
- Confirm by typing
ywhen prompted. - Test by browsing to
https://localhost/.
Method 3: PowerShell New-SelfSignedCertificate (Windows 10/Server 2016+)
Modern Windows versions provide the New-SelfSignedCertificate cmdlet, which is the most flexible approach.
Create a Basic Self-Signed Certificate
# Create a self-signed certificate
$cert = New-SelfSignedCertificate `
-DnsName "mysite.local" `
-CertStoreLocation "Cert:\LocalMachine\My" `
-FriendlyName "My Dev Certificate" `
-NotAfter (Get-Date).AddYears(2)
# Display the certificate thumbprint
Write-Host "Certificate Thumbprint: $($cert.Thumbprint)"
Create a SAN (Subject Alternative Name) Certificate
# Certificate valid for multiple hostnames
$cert = New-SelfSignedCertificate `
-DnsName "mysite.local", "www.mysite.local", "api.mysite.local", "localhost" `
-CertStoreLocation "Cert:\LocalMachine\My" `
-FriendlyName "Multi-Domain Dev Certificate" `
-NotAfter (Get-Date).AddYears(2) `
-KeyLength 2048 `
-KeyAlgorithm RSA `
-HashAlgorithm SHA256
Bind the Certificate to IIS via PowerShell
# Import the WebAdministration module
Import-Module WebAdministration
# Create an HTTPS binding for the Default Web Site
New-WebBinding -Name "Default Web Site" -Protocol https -Port 443
# Assign the certificate to the binding
$thumb = $cert.Thumbprint
Push-Location IIS:\SslBindings
Get-Item "Cert:\LocalMachine\My\$thumb" | New-Item 0.0.0.0!443
Pop-Location
Making Browsers Trust the Self-Signed Certificate
By default, browsers will display a security warning when accessing a site with a self-signed certificate. To suppress this warning on development machines, you can add the certificate to the Trusted Root Certification Authorities store.
On the Local Machine (PowerShell)
# Export the certificate
Export-Certificate -Cert $cert -FilePath "C:\certs\mysite.cer"
# Import into Trusted Root store
Import-Certificate -FilePath "C:\certs\mysite.cer" `
-CertStoreLocation "Cert:\LocalMachine\Root"
On the Local Machine (MMC)
- Press
Win + R, typemmc, and press Enter. - Go to File > Add/Remove Snap-in.
- Add the Certificates snap-in for Computer account > Local computer.
- Navigate to Personal > Certificates.
- Right-click the self-signed certificate, select All Tasks > Export, and export it.
- Navigate to Trusted Root Certification Authorities > Certificates.
- Right-click, select All Tasks > Import, and import the exported certificate.
Deploying Trust via Group Policy
For internal environments with many machines, deploy the certificate through Group Policy:
- Open Group Policy Management Console.
- Edit the appropriate GPO.
- Navigate to Computer Configuration > Policies > Windows Settings > Sécurité Settings > Public Key Policies > Trusted Root Certification Authorities.
- Right-click and import the self-signed certificate.
Certificate Expiration and Renewal
Self-signed certificates have an expiration date. Plan for renewal:
- Set calendar reminders before the certificate expires.
- For development environments, create certificates with longer validity periods (1-2 years).
- When renewing, create a new certificate and update the IIS binding to use it.
- Remove expired certificates from the certificate store to avoid confusion.
Sécurité Considerations
- Never use self-signed certificates in production for public-facing websites.
- Do not add self-signed certificates to trusted roots on production servers unless necessary for internal service-to-service communication.
- Use strong key lengths (2048-bit RSA minimum, 4096-bit preferred).
- Use SHA-256 or stronger hash algorithms.
- Consider Let’s Encrypt for free, automatically renewed CA-issued certificates for production use.
Résumé
Self-signed SSL certificates can be created through IIS Manager for IIS 7+, the SelfSSL tool for IIS 6.0, or PowerShell’s New-SelfSignedCertificate cmdlet for modern Windows. After creating the certificate, bind it to your website in IIS and optionally add it to the Trusted Root store on development machines to avoid browser warnings. Self-signed certificates are appropriate for development and internal use only. For production environments, use certificates from a trusted Certificate Authority.