releases.hashicorp.com's certificate expired

[dikhan]

Terraform Version

N/A

Terraform Configuration Files

N/A

Debug Output

$ wget https://releases.hashicorp.com/terraform/"$TF_VERSION"/terraform_"$TF_VERSION"_linux_amd64.zip
625--2022-05-26 03:30:03--  https://releases.hashicorp.com/terraform/0.13.6/terraform_0.13.6_linux_amd64.zip
626Resolving releases.hashicorp.com (releases.hashicorp.com)... 151.101.2.133, 151.101.66.133, 151.101.130.133, ...
627Connecting to releases.hashicorp.com (releases.hashicorp.com)|151.101.2.133|:443... connected.
628ERROR: cannot verify releases.hashicorp.com's certificate, issued by ‘/C=US/O=Let's Encrypt/CN=R3’:
629  Issued certificate has expired.
630To connect to releases.hashicorp.com insecurely, use `--no-check-certificate'.
631The command "wget https://releases.hashicorp.com/terraform/"$TF_VERSION"/terraform_"$TF_VERSION"_linux_amd64.zip" failed and exited with 5 during .

Expected Behavior

releases.hashicorp.com has a valid cert

Actual Behavior

See debug output above.

Steps to Reproduce

Additional Context

Ran into this issue when building the last PR created in the terraform-provider-openapi repo: dikhan/terraform-provider-openapi#347

Build showing the error: https://app.travis-ci.com/github/dikhan/terraform-provider-openapi/builds/251143536

[jbardin]

Hi @dikhan,

Thanks for filing the issue. Can you verify that you are still seeing this error from your location? Connecting to the same IP and hostname shows a valid certificate for me. Perhaps there was a stale edge node which was since been purged.

Thanks!

[zbodi74]

hi @jbardin, I also ran into this problem via a different IP address
Connecting to releases.hashicorp.com (199.232.26.133:443)
ssl_client: releases.hashicorp.com: certificate verification failed: certificate has expired

[piotrwielgolaski-tomtom]

I had this problem, but in my case it helped to update CA certificates with yum update ca-certificates

[jbardin]

Hi @zbodi74,

Is that the most recent output for you? From my location that IP also returns valid certificate:

% openssl s_client -showcerts -connect 199.232.26.133:443 -servername releases.hashicorp.com 2>/dev/null | openssl x509 -noout -dates
notBefore=May 25 13:30:17 2022 GMT
notAfter=Aug 23 13:30:16 2022 GMT

[s-garg]

Seeing this in one of our builds:

Connecting to releases.hashicorp.com (146.75.94.133:443)
ssl_client: releases.hashicorp.com: certificate verification failed: certificate has expired
wget: error getting response: Connection reset by peer

[AndyDean96]

We're seeing the same error in our builds too.
Running
Ubuntu 21.10
OpenSSL 1.1.1l 24 Aug 2021

SSL Error connecting to https://releases.hashicorp.com/vault-ssh-helper/0.1.4/vault-ssh-helper_0.1.4_linux_amd64.zip - SSL_connect returned=1 errno=0 state=error: certificate verify failed

[pdohertybcov]

I saw this error yesterday, and it was because releases.hashicorp.com was using a LetsEncrypt cert, and the client tried to verify the chain using the expired DST Root CA X3 cert, which is well documented here: https://scotthelme.co.uk/lets-encrypt-old-root-expiration/
I only ran into the error on old clients that haven't been patched to workaround the DST CA X3 cert.
Today, releases.hashicorp.com is shoiwng up for me with a GlobalSign cert.

[apparentlymart]

Thanks for sharing that context, @pdohertybcov!

Indeed then, it seems like what's going on here is:

• Most software relies on a system-wide store of trusted certificates in order to find the certificates and associated public keys for the root certificate authorities that server certificates are signed by.
• A server certificate can only be considered valid if every certificate in its signing chain -- all the way up to the root certificate in your system-wide certificate store -- is valid.
• Certificates always have an associated validity period. The CA system relies on the fact that relying systems will routinely have their store of trusted certificates updated so that new certificates with later validity periods can be rotated into place before the old certificates expire.

It seems from what's been discussed so far that some of you are working on systems whose root certificate store hasn't been kept up to date, and so some of the certificates that the CDN uses on releases.hashicorp.com have either expired certificates or no certificates in their certificate chains on your systems.

If that is true, then the typical resolution would be to update your system's certificate store to include newer certificates from various certificate authorities, including Let's Encrypt's updated root certificates. Since it is a certificate on your own system that has expired, rather than the one being returned by our servers, I think your only recourse will be to update your system to have up-to-date root certificates. How you would do that will depend on which operating system you are using.

If anyone is seeing the releases.hashicorp.com CDN endpoints returning a direct certificate that's expired or otherwise invalid -- that is, if the certificate carrying the hostname releases.hashicorp.com is the one that's failing, rather than one of the upstream certificates it's signed by, please do let us know!

[apparentlymart]

Hello again!

I haven't seen any more discussion about this since my previous comment, and I have seen some folks reporting success after updating their system's root certificates, so I'm going to close this issue on the assumption that my suggestion above is sufficient to resolve the issue.

Again if anyone is instead seeing that the direct certificate on releases.hashicorp.com is expired -- rather that that your system's root cert store lacks one of the upstream certificates our certificate relies on -- please let us know by opening a new issue. Thanks!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.