ALM, AzureDevOps, DevOps

x509: certificate signed by unknown authority

I encountered this error when moving my Azure Pipeline from Linux (ubuntu-latest) to windows (windows-latest). The pipeline tries to connect to a self-hosted Artifactory Server – but the error is a generic one and can occur with any Services that runs SSL with certificates from certain certificate authorities. In my case it was Quo Vadis.

What is the problem? The problem is, that Windows Server 2019 has less Root CAs installed then Windows 10 or Linux. You can verify this by running gci Cert:\CurrentUser\AuthRoot in a PowerShell on the server and compare it with the output from i.e. Windows 10. My Windows 10 has 30 entries – the Windows Server 2019 only 19.

So the solution to is simple – install the Root CA certificates on the server.

If you want to use the Azure hosted agents (i.e. windows-latest) you can use certutil to install the certificate in the pipeline. Add the certificates as .cer files to your repository and the following script to your yaml pipleine:

- script: | 
    certutil -f -addstore root certs\quovadis_rca_der.cer
    certutil -f -addstore root certs\quovadis_rca2_der.cer
    certutil -f -addstore root certs\quovadis_rca3_der.cer
    certutil -f -addstore root certs\quovadis_rcag3_der.cer
    certutil -f -addstore root certs\quovadis_rca2g3_der.cer
    certutil -f -addstore root certs\quovadis_rca3g3_der.cer
    
  displayName: 'Install Quo Vadis Root CA'

That’s it – now the error should be gone.

If you don’t know the root CA, open the URL that gives you the error in a browser (i.e. Chrome). Click the lock next to the URL and select Certificate (Valid). Under “Certification path” select the Root CA and click view details.

I downloaded the certificates from issuers web site – but you can also export the certificate here. Select “Copy to File…” on the “Details” tab and follow the wizard steps. Select DER format if asked and save the file to disk.

I filed an issue on GitHub and I hope it will be resolved so that we don’t need this workaround.

UPDATE: the issue on GitHub Actions and Azure DevOps Hosted Agents should be resolved. The certificates are now preinstalled.

9 thoughts on “x509: certificate signed by unknown authority”

  1. Thanks for sharing the solution!
    I tried it but ran into the error:

    DecodeFile returned The system cannot find the path specified. 0x80070003 (WIN32: 3 ERROR_PATH_NOT_FOUND)
    CertUtil: -addstore command FAILED: 0x80070003 (WIN32: 3 ERROR_PATH_NOT_FOUND)
    CertUtil: The system cannot find the path specified.

    My test yaml is as below. Am I missing something? Thanks a lot for your help!

    pool:
    vmImage: ‘windows-latest’

    steps:
    – script: |
    certutil -f -addstore root certs\quovadis_rca_der.cer
    certutil -f -addstore root certs\quovadis_rca2_der.cer
    certutil -f -addstore root certs\quovadis_rca3_der.cer
    certutil -f -addstore root certs\quovadis_rcag3_der.cer
    certutil -f -addstore root certs\quovadis_rca2g3_der.cer
    certutil -f -addstore root certs\quovadis_rca3g3_der.cer
    displayName: ‘Install Quo Vadis Root CA’

    Reply

  2. Does the file quovadis_rca_der.cer exist in the folder certs in the root of your sources folder? This error message occurs, if certutil cannot find the specified file. Check that the file exists.

    Reply

    1. Thanks! I missed one step in your original post. Now the installation of the certificates is working, but I am still getting the x509 error. Did you run your example with your own artifactory server? And that’s why it works with Quo Vadis certificates?

      Reply

  3. Yes. Exactly. What server do you use? Open your Artifactory URL in a browser (i.e. Chrome). If you right click the lock next to the URL and select “Cetificate” you see the certificate that is used. On the “Certification Path” tab you see the root and intermediate certificate. Export the root CA or go to the website of the issuer and download it there.

    Reply

      1. Thanks again for your help, Mike!
        My final issue was that I ran the script in an inital step of my orchestrating yaml. I didn’t realize that the agent machine switched with every step. Once I ran the installation script in each of the inline yaml files it worked.

  5. Hi,
    I’ve followed the instructions above but this solution didn’t work for me.
    I’m using a Windows 2016 system.

    Reply

Leave a comment