(only 5 minutes)
 

Self-Signed SSL for Intranets (Windows/IIS Guide) A free option for internal HTTPS access

A self-signed certificate lets you secure your intranet traffic with HTTPS, even without buying a certificate from a public authority. It's quick, free, and works well for small teams or testing - as long as you're okay with browser warnings or installing the cert manually on user devices.

What You'll Need

  • Admin access to your intranet server (Windows)
  • A hostname or internal IP for the intranet (e.g., intranet.local or 192.168.1.100)
  • Access to the server's certificate management tools (IIS, OpenSSL, etc.)

Options

  1. Windows Server Certificate (IIS)
  2. OpenSSL
  3. OpenSSL via Azure Cloud Shell
  4. OpenSSL via AWS CloudShell

Option 1) Step-by-Step: Windows Server (IIS)

  1. Open IIS Manager.
  2. Click the server name in the left pane, then select Server Certificates.
  3. Click Create Self-Signed Certificate in the right pane.
  4. Enter a friendly name (e.g., IntranetCert) and choose Personal store.
  5. In IIS, expand Sites in the left pane and select your intranet site.
  6. In the right pane, click Bindings.
  7. Click Add....
  8. Set Type to https. The port will default to 443.
  9. Set the Hostname to match your internal domain (e.g., intranet.simplifyit.local).
  10. Under SSL certificate, choose the certificate you just created.
  11. Click OK to finish and close the dialog.
  12. Important: If the certificate's hostname doesn't match the URL, browsers will show a warning.
  13. If you want browsers to trust the cert, export the certificate and install it in the Trusted Root store via GPO or manually.

Note: Users will see a browser warning unless the cert is trusted manually - more about that below.

Option 2) Create a Self-Signed Certificate with OpenSSL

You can use OpenSSL on Windows, Mac, or Linux to generate a self-signed certificate for your internal intranet. Here's how:

  1. Install OpenSSL if you haven't already
  2. Generate a private key and certificate:
    openssl req -x509 -nodes -days 825 -newkey rsa:2048 -keyout intranet.key -out intranet.crt -subj "/CN=internal.yoursite.com"
  3. Convert to .pfx format (for IIS or Windows import):
    openssl pkcs12 -export -out intranet.pfx -inkey intranet.key -in intranet.crt

Once downloaded, you can import the .pfx into IIS and enable HTTPS for your internal site:

  • Open IIS Manager
  • Click on your server name, then double-click Server Certificates
  • Click Import in the right-hand Actions menu and select your .pfx file
  • Once imported, go to your site, click Bindings, and add an HTTPS binding with the new certificate

Your intranet should now be accessible over HTTPS without browser warnings (except for expected self-signed certificate warnings).

Option 3) Use Azure Cloud Shell (No Install Required)

If you don't want to install OpenSSL locally, you can use Azure Cloud Shell right in your browser. It's free with any Azure account, includes OpenSSL out of the box, and works perfectly for generating internal-use SSL certificates.

  1. Go to shell.azure.com and launch a Bash shell
  2. Generate a self-signed certificate:
    openssl req -x509 -nodes -days 825 -newkey rsa:2048 -keyout intranet.key -out intranet.crt -subj "/CN=internal.yoursite.com"
  3. Convert it to .pfx format for IIS:
    openssl pkcs12 -export -out intranet.pfx -inkey intranet.key -in intranet.crt
  4. Move it to your cloud drive: mv intranet.pfx ~/clouddrive
  5. Download the file from the Cloud Shell file browser

Once downloaded, you can import the .pfx into IIS and enable HTTPS for your internal site:

  • Open IIS Manager
  • Click on your server name, then double-click Server Certificates
  • Click Import in the right-hand Actions menu and select your .pfx file
  • Once imported, go to your site, click Bindings, and add an HTTPS binding with the new certificate

Your intranet should now be accessible over HTTPS without browser warnings (except for expected self-signed certificate warnings).

Option 4) Use AWS CloudShell (No Install Required)

If you use AWS, AWS CloudShell is another no-install option. It runs in your browser, comes with OpenSSL preinstalled, and gives you instant terminal access to generate certs.

  1. Log in to the AWS CloudShell Console
  2. Generate a self-signed certificate:
    openssl req -x509 -nodes -days 825 -newkey rsa:2048 -keyout intranet.key -out intranet.crt -subj "/CN=internal.yoursite.com"
  3. Convert to .pfx:
    openssl pkcs12 -export -out intranet.pfx -inkey intranet.key -in intranet.crt
  4. Click the folder icon in the top right to download your file

Once downloaded, you can import the .pfx into IIS and enable HTTPS for your internal site:

  • Open IIS Manager
  • Click on your server name, then double-click Server Certificates
  • Click Import in the right-hand Actions menu and select your .pfx file
  • Once imported, go to your site, click Bindings, and add an HTTPS binding with the new certificate

Your intranet should now be accessible over HTTPS without browser warnings (except for expected self-signed certificate warnings).

Redirect HTTP to HTTPS (IIS / web.config)

After setting up your self-signed SSL certificate, you'll want to make sure all users are redirected to the secure HTTPS version of your intranet. You can do this using IIS URL Rewrite rules.

Step-by-Step:

  1. Make sure the URL Rewrite Module is installed on your IIS server.
  2. Open or edit your site's web.config file.
  3. Inside the <system.webServer> section, add the following:
<rewrite>
  <rules>
    <rule name="Redirect to HTTPS" enabled="true" stopProcessing="true">
      <match url="(.*)" />
      <conditions>
        <add input="{HTTPS}" pattern="off" ignoreCase="true" />
      </conditions>
      <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
    </rule>
  </rules>
</rewrite>

Once saved, all HTTP requests will automatically redirect to HTTPS.

Export a .CER File from MMC

  1. Click Start, type mmc, and press Enter.
  2. Go to File > Add/Remove Snap-in.
  3. Add Certificates for the Computer account.
  4. Navigate to Personal > Certificates.
  5. Find your self-signed certificate (look under Issued To).
  6. Right-click it > All Tasks > Export.
  7. Choose No, do not export the private key.
  8. Select DER encoded binary X.509 (.CER).
  9. Save the file. This is your .cer file to deploy via GPO.

Make the Certificate Trusted Across Your Institution

By default, Chrome and Edge will show a security warning for self-signed certificates. To eliminate this warning across all machines in your environment, add the certificate to each workstation's Trusted Root Certification Authorities store.

Option 1: Use Group Policy (Recommended for Domain Environments)

  1. Open Group Policy Management on your domain controller.
  2. Create a new GPO or edit an existing one that applies to your intranet users.
  3. Navigate to:
    Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities
  4. Right-click and select Import, then upload your self-signed certificate (.cer file).
  5. Apply and update group policy: gpupdate /force on each machine or wait for normal policy refresh.

This will silently trust the certificate on all domain-joined devices - no more warnings in Chrome, Edge, or Internet Explorer.

Option 2: Manual Trust on a Single Machine (For Testing or Small Offices)

  1. Double-click the .cer file.
  2. Click Install Certificate.
  3. Select Local Machine.
  4. Choose Place all certificates in the following store and browse to Trusted Root Certification Authorities.
  5. Click Finish and confirm when prompted.

This will remove the security warning on that machine for your intranet.

Pros and Cons of Self-Signed Certs

  • Pros: Free, fast, and no outside involvement
  • Cons: Not trusted by default, requires manual work on each device
  • Not ideal for larger teams or compliance-focused environments

When to Use Something Else

If your intranet is used by more than a few staff - or if you want to eliminate browser warnings and improve compliance - consider a wildcard certificate or internal certificate authority.

Common Questions

What is a self-signed SSL certificate?
A self-signed certificate is one you generate and sign yourself, rather than purchasing it from a public certificate authority. It's useful for internal or test environments where browser trust warnings are acceptable or can be managed.
Why does my browser say the certificate isn't trusted?
Browsers don't trust self-signed certificates by default. To remove warnings, you need to install the certificate on each device or use Group Policy to distribute it within your organization.
Can I use a self-signed certificate with IIS on Windows Server?
Yes. IIS makes it easy to create and bind a self-signed certificate for your intranet site. You'll find the option in the Server Certificates section of IIS Manager.
How do I redirect HTTP to HTTPS on my intranet?
You can use a web.config rule with IIS URL Rewrite to automatically redirect all HTTP traffic to HTTPS, ensuring users always access the secure version.
What's the best way to trust the certificate across all workstations?
For domain environments, use Group Policy to deploy the certificate to all domain-joined devices' Trusted Root Certification Authorities store.
Are self-signed certificates secure?
Yes, they provide encrypted HTTPS traffic. The main risk is that they're not trusted by default and can't be revoked centrally. For production use or larger teams, a wildcard or internal CA is a better option.
When should I use a wildcard certificate or internal CA instead?
If you need widespread trust, manage multiple subdomains, or need centralized control and revocation, a wildcard certificate or internal CA is the better choice for internal HTTPS.

Related Resources

 
 

Why Bank Employee Onboarding Fails Without Automation

Published July 28, 2025

Manual onboarding creates compliance gaps and delays. Learn why banks need automated onboarding to keep IT, HR, and compliance aligned from day one.

Stop the Guesswork: How Financial Institutions Can Finally Fix Their Outdated Procedures

Published July 26, 2025

Outdated procedures create risk and confusion. Learn how banks and credit unions can centralize, control, and maintain procedures using a modern intranet platform.

Intranet Governance That Works: How Financial Institutions Stay Compliant Without the Chaos

Published July 24, 2025

Tired of outdated files and audit scrambles? A simple governance framework helps banks and credit unions keep intranet content accurate, owned, and compliant - without chaos.

Popular Pages
 
SharePoint Alternative • Form Builder • Bank Intranets • Credit Union Intranets • Bank Help Desk • Document Repository • U.S. Based Banking Intranet • Data-Secure Intranet for Banks & Credit Unions
 
✦ trusted in banking since 2004 ✦