Next release could use a CA bundle update

[ntavares]

Hi,

I just came across this, Sectigo has gone through a root CA migration: https://www.sectigo.com/sectigo-public-root-cas-migration

This was done in a timely manner, but it seems that the blackbox image didn't catch up: the CA bundle is too old. Looking at the [mozilla ca bundle|https://curl.se/docs/caextract.html] I can see the new CA's are there, but they're not found in the latest blackbox-exporter image.

# Mozilla CA Bundle
$ openssl storeutl -noout -text -certs cacert-2025-05-20.pem  | grep Subject: | grep -i Sectigo
        Subject: C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root E46
        Subject: C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46

# CA Bundle on the latest image:
$ openssl storeutl -noout -text -certs ca-certificates.crt  | grep Subject: | grep -i Sectigo
$ 

This is an easy one to fix, not sure how I could help here?

[ianhinder]

According to that Sectigo page,

How will you ensure backwards compatibility with legacy systems? All our new Root CAs, have been cross-signed by both of our long standing Root CAs:

AAA Certificate Services USERTrust RSA Certification Authority (For RSA) USERTrust ECC Certification Authority (For ECC) Through these cross-signings, we extend the ubiquity of the new Root CAs, so they are also trusted on legacy systems that may not know about these new CA certificates, but do know about the long standing Root CAs mentioned above.

So it should still be possible to validate a cert signed up to the new root certs, since the new root certs are cross-signed with other existing root certs. Unless the library used in blackbox doesn't support this cross-signing?

[winem]

Hi,

I noticed that newer Sectigo certificates no longer seem to be cross-signed which causes the blackbox-exporter to report the SSL handshake as failed:

level=ERROR source=http.go:474 msg="Error for HTTP request" module=http_get_with_accessToken target=https://www.neh.gov.ie/ err="Get \"https://54.230.114.27/\": tls: failed to verify certificate: x509: certificate signed by unknown authority"

An example is www.neh.gov.ie:

openssl s_client -servername neh.gov.ie -connect neh.gov.ie:443 -showcerts

depth=2 C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
verify return:1
depth=1 C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
verify return:1
depth=0 CN=neh.gov.ie
verify return:1
---
Certificate chain
 0 s:CN=neh.gov.ie
   i:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep 26 00:00:00 2025 GMT; NotAfter: Oct 15 23:59:59 2026 GMT
[...]
 1 s:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
   i:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Mar 21 23:59:59 2036 GMT
[...]
 2 s:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
   i:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Mar 21 23:59:59 2046 GMT
[...]
SSL handshake has read 5256 bytes and written 389 bytes
Verification: OK

I would expect to see here that the certificate was cross-signed. Otherwise, if it actually is cross-signed it would mean that the libs used by the blackbox-exporter can not handle the situation properly but I would be surprised and expect more issues if that's the case.

So I'd vote to add the Sectigo certificates to the trust store. I'd also be happy to contribute to the project so I'll have a look at the details to get an idea what it takes to update the trusted certificates next week. But please don't wait for it, I guess it's a smaller task.

[aebm]

Hi, I have reported the issue in the repo from where this image gets built https://github.com/prometheus/busybox/issues/65

A work around is to launch a debian bookworm image

sudo docker run --rm -ti --network=host --name temp debian:bookworm-slim

Inside the container install ca-certificates

apt update
apt install -y ca-certificates

Then from outside, copy the ca-certificates.crt file of the container and build a temp blackbox-exporter image [1]

sudo docker cp wip:/etc/ssl/certs/ca-certificates.crt .
sudo docker build -t blackbox-temp .

[1] Dockerfile

FROM prom/blackbox-exporter:master

COPY ca-certificates.crt /etc/ssl/certs/ca-certificates.crt