Resolve the 'Connection isn't secure' warning in Azure DevOps by trusting the self-signed certificate's root authority on every client machine. You must export the .cer file from your server and import it into the Trusted Root Certification Authorities store of each browser or agent. This action validates the certificate chain, eliminating the security alert for all users accessing the instance.
Understanding the Security Warning
Browsers and operating systems maintain strict trust stores to prevent man-in-the-middle attacks. When you install Azure DevOps Server with a self-signed certificate, the certificate is not signed by a public Certificate Authority (CA) that is pre-installed in these trust stores. Consequently, clients cannot verify the identity of the server, leading to the warning. This is not a bug in Azure DevOps but a standard security feature of modern web browsers and Windows.
To fix this, you need to manually add the certificate to the trusted list on each device that accesses the portal. This process ensures that the client recognizes the self-signed certificate as valid because it trusts the issuer.
Exporting the Certificate from the Server
The first step is to retrieve the certificate file from the Azure DevOps Server machine. You can do this via the Internet Information Services (IIS) Manager or by using PowerShell.
- Open IIS Manager on the Azure DevOps Server machine.
- Select the server node in the left-hand connection pane.
- Double-click Server Certificates in the Features view.
- Locate the certificate used for your Azure DevOps site. It usually matches the domain name configured during installation.
- Right-click the certificate and select Export....
- Save the file as a
.cerfile. Do not include the private key; only the public certificate is needed for client machines.
Alternatively, you can use PowerShell to export the certificate. Run the following command to find the certificate thumbprint:
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*YourDomainName*" }Once you have the thumbprint, export it using:
$cert = Get-ChildItem -Path Cert:\LocalMachine\My\
[System.IO.File]::WriteAllBytes("C:\AzureDevOpsCert.cer", $cert.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)) Importing the Certificate on Client Machines
You must repeat this process for every computer that needs to access Azure DevOps, including developer workstations and build agents. The most effective method is importing the certificate into the Trusted Root Certification Authorities store.
- Copy the
.cerfile to the client machine. - Double-click the certificate file to open the Certificate Import Wizard.
- Click Next and choose Place all certificates in the following store.
- Click Browse and select Trusted Root Certification Authorities. Ensure you select the Local Machine store if you want it to apply to all users, or Current User for just yourself.
- Complete the wizard and confirm the success message.
After importing, restart your browser. The warning should disappear. If it persists, clear the browser cache or perform an InPrivate / Incognito session to ensure the old cached error is not being displayed.
Configuring Build Agents
Build agents are often overlooked when dealing with SSL warnings. If your self-hosted agents cannot connect to Azure DevOps due to this warning, they will fail to pick up jobs. You must install the same certificate on the agent machine in the Trusted Root store. For Microsoft-hosted agents, you cannot control the environment, so you must use a publicly trusted certificate for those scenarios. Self-signed certificates are only suitable for local networks where you control the client devices.
If you are using a load balancer or reverse proxy in front of Azure DevOps, ensure that the certificate installed there is also trusted. The termination point of the SSL connection determines which certificate the clients see. In many enterprise setups, the load balancer presents a corporate internal CA certificate, which should already be distributed to all employee machines via Group Policy.
Troubleshooting Common Issues
Sometimes, even after importing the certificate, the warning may persist. Check the following:
- Wrong Store: Ensure you imported it into "Trusted Root Certification Authorities," not just "Personal." Clients do not trust personal stores for server validation.
- Expired Certificate: Verify that the self-signed certificate has not expired. Self-signed certs often default to one year.
- Name Mismatch: The Subject Alternative Name (SAN) in the certificate must match the URL you are typing into the browser. If you access it by IP address but the cert is for a hostname, the warning will remain.
For more information on managing source code and pipelines in this environment, see Source Code Management and Azure DevOps Pipeline with PowerShell. Additionally, if you encounter other installation quirks, check out Strange pop-up with 'Alt+PrintScreen' warning during installation.
Frequently Asked Questions
Can I bypass the warning without installing the certificate?
No, modern browsers strictly block connections to sites with untrusted certificates. You cannot simply click through to access Azure DevOps securely. You must trust the certificate authority on the client machine.
Do I need to reinstall Azure DevOps after fixing the certificate?
No, you do not need to reinstall the application. Once the certificate is properly exported and imported into the trusted root store on the client, the connection will be recognized as secure immediately.
Why does the warning appear on some computers but not others?
This happens because the certificate was only imported into the trusted root store on the specific machines where it was manually added. Other machines that have not received the certificate still see it as untrusted.
Is it safe to use self-signed certificates in production?
Self-signed certificates are generally not recommended for public-facing production environments because they require manual trust on every client. They are acceptable for internal development servers or isolated test environments where you control all client devices.
How do I update the certificate if it expires?
If the certificate expires, you must generate a new one, export it, and replace the old certificate in both the IIS server store and the client machines' trusted root stores. Browsers will revert to showing warnings once the current certificate becomes invalid.