curlssl-certificateopam

opam init fails because curl fails to verify the certificate

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?

Solution

  • 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: