opam init fails because curl fails to verify the certificate

Question

I am trying to set up OPAM on Debian Stretch (in a chroot jail within a CI environment). After installing opam via apt, I run opam init -y, which fails with the following output:

Error:  Command "curl --write-out %{http_code}\\n --retry 3 --retry-delay 2 --compressed -OL https://opam.ocaml.org/urls.txt" failed:
# opam-version         1.2.2
# os                   linux
# command              curl --write-out %{http_code}\n --retry 3 --retry-delay 2 --compressed -OL https://opam.ocaml.org/urls.txt
# path                 /tmp/opam-57077-c61e7b
# exit-code            60
# env-file             /home/runner/.opam/log/log-57077-d2d111.env
# stdout-file          /home/runner/.opam/log/log-57077-d2d111.out
# stderr-file          /home/runner/.opam/log/log-57077-d2d111.err
### stdout ###
# 000
### stderr ###
# [...]
# curl performs SSL certificate verification by default, using a "bundle"
#  of Certificate Authority (CA) public keys (CA certs). If the default
#  bundle file isn't adequate, you can specify an alternate file
#  using the --cacert option.
# If this HTTPS server uses a certificate signed by a CA represented in
#  the bundle, the certificate verification probably failed due to a
#  problem with the certificate (it might be expired, or the name might
#  not match the domain name in the URL).
# If you'd like to turn off curl's verification of the certificate, use
#  the -k (or --insecure) option.

All I can see here is that the certificate fails, but not why: Has it expired (or is not valid yet)? Is the issuer unknown? What is it being verified against?

Re-running opam init with the -verbose switch did not provide any further info that I found helpful.

Installing ca-certificates prior to running opam init also did not help.

Manually running curl -v https://opam.ocaml.org/urls.txt tells me “the certificate” has expired (but not if it is the server certificate or one of the certificates in the chain). However, when I do the same on my local machine, the request succeeds. Running date in the chroot jail returns the correct time. What gives?

Answer 1

Updating the VM image from stretch to buster (which is the immediate successor – bullseye resulted in other errors which I am still investigating) fixed the error.

What presumably happened is that, while the server certificate is still valid (which I verified with a browser), one of the issuing CA (there is a root cert and an intermediate one) had expired. (Not sure if the server supplied one, but apparently curl used a local copy.) Later Debian releases seem to have a more recent version of that certificate, with the same key but a new expiration date.

For everybody hitting the same issue, here’s what to do:

• Check the error message from opam init for the URL that fails.
• Run curl -v for the failing URL:
  • What CA cert path is being used by curl? Does it have the latest certificates installed? (On Debian-based distros, this should be in the ca-certificates package.)
  • What is the precise certificate verification error?
• Do the same on another machine, possibly also with your regular browser. Are you getting the same results?
• If the certificate is reported expired (or not yet valid) on one machine but OK on another:
  • Do all machines have the correct date and time? If the date/time is off (and outside the validity period of at least one certificate in the chain), verification will fail. Solution: set the correct date and time.
  • Does the machine have the latest version of all CA and intermediate certificates? If one certificate in the chain has expired, replace it with a new one – either by updating the package that holds the certificates (ca-certificates on Debian), by updating to a newer version of your distribution (if that is an option), or by manually adding the missing cert file.