I have noticed that the connection in both firefox as chromium work without certificate issues for the URL https://biblio.brussels/iguana/Proxy.SearchRequest.cls Behind this is the intermediate certificate which results in errors in tools like wget and curl. "Unable to locally verify the issuer's authority.", "curl: (60) SSL certificate problem: unable to get local issuer certificate" 1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018 i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign What is the best upstream candidate to address these issues? This fails on Ubuntu as well. Would this be dev-libs/nss? Reproducible: Always
The site you are connected to has misconfigured their servers. It just happens to work in Chrome because Google ships some intermediate certificates as well as root certificates. The server right now hands out ONE certificate: Certificate chain 0 s:C = BE, ST = Brussels-Capital Region, L = Brussels, O = ASBL i-CITY VZW, CN = *.biblio.brussels i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018 It should ALSO be providing this intermediate: Issuer: OU=GlobalSign Root CA - R3, O=GlobalSign, CN=GlobalSign Subject: C=BE, O=GlobalSign nv-sa, CN=GlobalSign RSA OV SSL CA 2018 As seen here: https://www.tbs-certificates.co.uk/FAQ/en/gsrsaovsslca2018.html If you wanted to get that intermediate introduced, it would be the Mozilla NSS team (but I think they are unlikely to agree to do that). If you wanted to contact the Library, I don't know where best, but irisline@cirb.irisnet.be might work, based on the IP WHOIS data.
Dear Robin, thanks for your elaborative answer. When I requested the website with OpenSSL I ended up with three certificates; openssl s_client -showcerts -servername server -connect biblio.brussels:443 > /tmp/cacert.pem depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign verify return:1 depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018 verify return:1 depth=0 C = BE, ST = R\C3\A9gion de Bruxelles-Capitale, L = Bruxelles, O = ASBL GIAL / i-City VZW, CN = *.gial.be verify return:1
(In reply to Stefan de Konink from comment #2) > Dear Robin, thanks for your elaborative answer. When I requested the website > with OpenSSL I ended up with three certificates; > > openssl s_client -showcerts -servername server -connect biblio.brussels:443 > > /tmp/cacert.pem > > depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign > verify return:1 > depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018 > verify return:1 > depth=0 C = BE, ST = R\C3\A9gion de Bruxelles-Capitale, L = Bruxelles, O = > ASBL GIAL / i-City VZW, CN = *.gial.be > verify return:1 (I'm on the base-system alias, you don't need to notify me directly). Your "-servername server" block triggers their system to provide the default certificate, which is correctly configured with the intermediate, but doesn't help your problem. ==== $ COMMON="openssl s_client -connect biblio.brussels:443 " # Capture the certs for both ServerName inputs: $ false | $COMMON -showcerts -servername biblio.brussels >certs-biblio.brussels $ false | $COMMON -showcerts -servername server >certs-server # Compare the sizes trivially $ ls -la certs-biblio.brussels certs-server -rw-r--r-- 1 robbat2 users 3736 2021-12-29 13:43 certs-biblio.brussels -rw-r--r-- 1 robbat2 users 6719 2021-12-29 13:43 certs-server # Compare the OpenSSL behavior: # firstly, with the correct ServerName input, it returns the certs without the intermediate, so it's not usable $ false | $COMMON -verify_return_error -servername biblio.brussels CONNECTED(00000003) depth=0 C = BE, ST = Brussels-Capital Region, L = Brussels, O = ASBL i-CITY VZW, CN = *.biblio.brussels verify error:num=20:unable to get local issuer certificate 140088237438784:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1914: ... # Then, send some OTHER ServerName that does not match the SNI rules on the server side: # It returns the *default* certificate on that host, and along with the CORRECT intermediate. # That default certificate is for *.gial.be, which also doesn't match the biblio.brussels name. $ false | $COMMON -verify_return_error -servername server CONNECTED(00000003) depth=2 OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign verify return:1 depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018 verify return:1 depth=0 C = BE, ST = R\C3\A9gion de Bruxelles-Capitale, L = Bruxelles, O = ASBL GIAL / i-City VZW, CN = *.gial.be verify return:1 --- Certificate chain 0 s:C = BE, ST = R\C3\A9gion de Bruxelles-Capitale, L = Bruxelles, O = ASBL GIAL / i-City VZW, CN = *.gial.be i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018 1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign RSA OV SSL CA 2018 i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign 2 s:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign i:OU = GlobalSign Root CA - R3, O = GlobalSign, CN = GlobalSign --- ====
Actually, I realize their default one is also slightly misconfigured: it served the self-signed CA cert as well, which isn't needed (and is a mis-configuration in some cases).
