Thanks for confirming. So in theory, a minimal official ubuntu Docker image can also be used to follow the steps and make suggestions on things to check.
docker run -ti ubuntu:latest bash
apt update && apt install -y curl
The full version output is interesting to learn which libraries curl is linked against - OpenSSL, or some alternative implementation like libreSSL. Could be a direction to search for bugs.
root@8634df6834f6:/# curl --version
curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets
Knowing that OpenSSL comes to play, we can switch the debugging client to openssl and connect to the package server.
Please run the command below also on your server, and post the output. I am sharing mine for comparison. Depending on the server, you may need to run apt -y install openssl first.
root@8634df6834f6:/# openssl s_client -connect packages.gitlab.com:443
CONNECTED(00000003)
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify return:1
depth=1 C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = gitlab.com
verify return:1
---
Certificate chain
0 s:C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = gitlab.com
i:C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3
1 s:C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3
i:C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
---
---
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2705 bytes and written 391 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Next, let’s print the CA Certificate file.
root@8634df6834f6:/# ls -la /etc/ssl/certs/ca-certificates.crt
-rw-r--r-- 1 root root 195453 Jun 10 17:36 /etc/ssl/certs/ca-certificates.crt
root@8634df6834f6:/# awk -v cmd='openssl x509 -noout -subject' '
/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt
The output can be compared to what is offered when connecting to the server, -showcerts for the openssl command.
openssl s_client -showcerts -connect packages.gitlab.com:443
At this point, I strongly believe that there is a HTTP/TLS proxy in front of you, which intercepts the traffic, and thus presents the wrong CA certificate. We can verify that together by analysing your output from the commands above.