| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
On 4/7/25 3:23 PM, Bruce Dubbs wrote:
> On 4/7/25 3:01 PM, "Douglas R. Reno" ([email protected] via blfs-dev
> Mailing List) wrote:
>> Good afternoon folks,
>>
>> I'm in the process of continuing to rebuild my development system, and I've
>> encountered an issue with make-ca.
>>
>> When running "make-ca -g", I get the following output:
>>
>> renodr [ /tmp ]$ sudo make-ca -g
>> Checking for new version of certdata.txt...done.
>> Unable to get revision from server! Exiting.
>>
>> In the past, this has been due to a certificate problem with the bundled mozilla-
>> ca- root certificate that we install with make-ca.
>>
>> This time appears to be a bit different. I reviewed the output of certdata.txt.log
>> in the temporary directory that was created, and the certificate validation looks
>> fine.
>>
>> The problem now is that the download URL for the certificate data redirects from
>> hg.mozilla.org to hg-edge.mozilla.org. I noticed that in my web browser, but it
>> does it via wget as well:
>>
>> renodr [ /sources ]$ wget https://hg.mozilla.org/projects/nss/raw-file/tip/lib/
>> ckfw/ builtins/certdata.txt
>> --2025-04-07 14:37:49-- https://hg.mozilla.org/projects/nss/raw-file/tip/lib/ckfw/
>> builtins/certdata.txt
>> Resolving hg.mozilla.org (hg.mozilla.org)... 63.245.208.203
>> Connecting to hg.mozilla.org (hg.mozilla.org)|63.245.208.203|:443... connected.
>> HTTP request sent, awaiting response... 302 Found
>> Location: https://hg-edge.mozilla.org/projects/nss/raw-file/tip/lib/ckfw/builtins/
>> certdata.txt [following]
>> --2025-04-07 14:37:49-- https://hg-edge.mozilla.org/projects/nss/raw-file/tip/lib/
>> ckfw/builtins/certdata.txt
>> Resolving hg-edge.mozilla.org (hg-edge.mozilla.org)... 151.101.1.91, 151.101.65.91,
>> 151.101.193.91, ...
>> Connecting to hg-edge.mozilla.org (hg-edge.mozilla.org)|151.101.1.91|:443...
>> connected.
>> HTTP request sent, awaiting response... 200 OK
>> Length: 1403491 (1.3M) [text/plain]
>> Saving to: ‘certdata.txt’
>>
>> certdata.txt
>> 100%[=====================================================================>] 1.34M
>> 4.48MB/s in 0.3s
>>
>> 2025-04-07 14:37:50 (4.48 MB/s) - ‘certdata.txt’ saved [1403491/1403491]
>>
>>
>> I suspect what's happening here is that since the URL is now redirecting, the
>> download will fail. We're using s_client from OpenSSL to download the file (via
>> openssl s_client). The certificate for hg-edge.mozilla.org is different than that
>> of hg.mozilla.org, as it is signed with LetsEncrypt instead of DigiCert. Here's an
>> example of what appears if we just change the url from 'hg.mozilla.org' to 'hg-
>> edge.mozilla.org':
>>
>> CONNECTED(00000003)
>> ---
>> Certificate chain
>> 0 s:CN=hg-edge.mozilla.org
>> i:C=US, O=Let's Encrypt, CN=R11
>> a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>> v:NotBefore: Mar 20 13:11:15 2025 GMT; NotAfter: Jun 18 13:11:14 2025 GMT
>> 1 s:C=US, O=Let's Encrypt, CN=R11
>> i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
>> a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>> v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
>> ---
>> no peer certificate available
>> ---
>> No client certificate CA names sent
>> Server Temp Key: X25519, 253 bits
>> ---
>> SSL handshake has read 2816 bytes and written 344 bytes
>> Verification error: unable to get local issuer certificate
>> ---
>> New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
>> Protocol: TLSv1.3
>> This TLS version forbids renegotiation.
>> Compression: NONE
>> Expansion: NONE
>> No ALPN negotiated
>> Early data was not sent
>> Verify return code: 20 (unable to get local issuer certificate)
>> ---
>>
>>
>> Meanwhile, the old certificate chain was:
>>
>> CONNECTED(00000003)
>> ---
>> Certificate chain
>> 0 s:C=US, ST=California, L=San Francisco, O=Mozilla Foundation, CN=hg.mozilla.org
>> i:C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
>> a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
>> v:NotBefore: Sep 3 00:00:00 2024 GMT; NotAfter: Sep 18 23:59:59 2025 GMT
>> 1 s:C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
>> i:C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root G2
>> a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
>> v:NotBefore: Mar 30 00:00:00 2021 GMT; NotAfter: Mar 29 23:59:59 2031 GMT
>> ---
>> [Certificate Trimmed]
>>
>> -----END CERTIFICATE-----
>> subject=C=US, ST=California, L=San Francisco, O=Mozilla Foundation, CN=hg.mozilla.org
>> issuer=C=US, O=DigiCert Inc, CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
>> ---
>> No client certificate CA names sent
>> Peer signing digest: SHA256
>> Peer signature type: RSA-PSS
>> Server Temp Key: ECDH, prime256v1, 256 bits
>> ---
>> SSL handshake has read 4191 bytes and written 777 bytes
>> Verification: OK
>> ---
>> New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
>> Protocol: TLSv1.3
>> Server public key is 4096 bit
>> This TLS version forbids renegotiation.
>> 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
>> Session-ID: 996C0B9D6523BBA88A86FA8F94D8D391A64098B2F2C80B7685637F81E2EFDFC7
>> Session-ID-ctx:
>> Resumption PSK:
>> 05E1FE928267D4412B2F3E097FE6AC3773EEC6D3315A1A81DE440A97E9505082E3AF319F8DAFE522905902A42BA86707
>> PSK identity: None
>> PSK identity hint: None
>> SRP username: None
>> TLS session ticket lifetime hint: 14400 (seconds)
>> TLS session ticket:
>> 0000 - 01 b3 14 6b e9 bf 63 c5-67 8f 46 7d 8e eb 31 e9 ...k..c.g.F}..1.
>> 0010 - d2 f1 8e c7 02 4a 5d b6-9d f2 a0 42 fb 85 f2 ac .....J]....B....
>> 0020 - 74 fb 80 1c 63 a5 f0 c8-ab c5 90 4e 4d a0 1d 39 t...c......NM..9
>> 0030 - 7e e4 31 b2 5e 46 80 23-c4 62 e8 cd b1 e3 67 88 ~.1.^F.#.b....g.
>> 0040 - a4 48 0b 66 58 ad 54 90-73 35 79 be fb 77 99 ac .H.fX.T.s5y..w..
>> 0050 - 04 5e e4 b5 53 42 15 55-82 8f 78 23 b0 74 5e b9 .^..SB.U..x#.t^.
>> 0060 - 2d a8 d3 46 07 ec f4 25-85 1f ec 5b 13 95 70 a3 -..F...%...[..p.
>> 0070 - 3a d8 04 9d f9 de 85 f2-ed 2b ab 12 52 d6 98 df :........+..R...
>> 0080 - 0c 95 2d 2b 2b 79 4a b7-ff 0e 50 fe c5 77 bd 3f ..-++yJ...P..w.?
>> 0090 - b2 c3 65 a3 22 55 fa 26-0d c0 16 8b 8f 01 56 05 ..e."U.&......V.
>> 00a0 - 90 fa 24 96 85 06 32 20-e4 f2 09 81 05 69 14 65 ..$...2 .....i.e
>> 00b0 - 7a z
>>
>> Start Time: 1744053927
>> Timeout : 7200 (sec)
>> Verify return code: 0 (ok)
>> Extended master secret: no
>> Max Early Data: 0
>> ---
>> read R BLOCK
>> closed
>>
>>
>> (Note that the above output happens if you run make-ca -g as it is shipped
>> currently, but you never get a certdata.txt file and the reason for that wasn't
>> originally apparent to me - which is why I tried downloading the file in a web
>> browser and via wget, and that redirected to hg-edge.mozilla.org).
>>
>> I've also tried downloading certdata.txt with cURL and here's the output from that:
>>
>> root [ /tmp/tmp.SMbxC0i3cs ]# curl https://hg.mozilla.org/projects/nss/raw-file/
>> tip/ lib/ckfw/builtins/certdata.txt -v
>> * Host hg.mozilla.org:443 was resolved.
>> * IPv6: (none)
>> * IPv4: 63.245.208.203
>> * Trying 63.245.208.203:443...
>> * ALPN: curl offers h2,http/1.1
>> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
>> * CAfile: none
>> * CApath: /etc/ssl/certs
>> * TLSv1.3 (IN), TLS handshake, Server hello (2):
>> * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
>> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
>> * TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
>> * TLSv1.3 (IN), TLS handshake, Server hello (2):
>> * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
>> * TLSv1.3 (IN), TLS handshake, Certificate (11):
>> * TLSv1.3 (IN), TLS handshake, CERT verify (15):
>> * TLSv1.3 (IN), TLS handshake, Finished (20):
>> * TLSv1.3 (OUT), TLS handshake, Finished (20):
>> * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / secp256r1 / RSASSA-PSS
>> * ALPN: server accepted h2
>> * Server certificate:
>> * subject: C=US; ST=California; L=San Francisco; O=Mozilla Foundation;
>> CN=hg.mozilla.org
>> * start date: Sep 3 00:00:00 2024 GMT
>> * expire date: Sep 18 23:59:59 2025 GMT
>> * subjectAltName: host "hg.mozilla.org" matched cert's "hg.mozilla.org"
>> * issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
>> * SSL certificate verify ok.
>> * Certificate level 0: Public key type RSA (4096/152 Bits/secBits), signed using
>> sha256WithRSAEncryption
>> * Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using
>> sha256WithRSAEncryption
>> * Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using
>> sha256WithRSAEncryption
>> * Connected to hg.mozilla.org (63.245.208.203) port 443
>> * using HTTP/2
>> * [HTTP/2] [1] OPENED stream for https://hg.mozilla.org/projects/nss/raw-file/tip/
>> lib/ckfw/builtins/certdata.txt
>> * [HTTP/2] [1] [:method: GET]
>> * [HTTP/2] [1] [:scheme: https]
>> * [HTTP/2] [1] [:authority: hg.mozilla.org]
>> * [HTTP/2] [1] [:path: /projects/nss/raw-file/tip/lib/ckfw/builtins/certdata.txt]
>> * [HTTP/2] [1] [user-agent: curl/8.12.1]
>> * [HTTP/2] [1] [accept: */*]
>> > GET /projects/nss/raw-file/tip/lib/ckfw/builtins/certdata.txt HTTP/2
>> > Host: hg.mozilla.org
>> > User-Agent: curl/8.12.1
>> > Accept: */*
>> >
>> * Request completely sent off
>> * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
>> < HTTP/2 302
>> < content-type: text/html
>> < date: Mon, 07 Apr 2025 19:56:06 GMT
>> < location: https://hg-edge.mozilla.org/projects/nss/raw-file/tip/lib/ckfw/
>> builtins/ certdata.txt
>> < access-control-allow-origin: *
>> < content-length: 0
>> <
>> * Connection #0 to host hg.mozilla.org left intact
>>
>> Changing the URL to say 'hg-edge.mozilla.org' does result in cURL dumping the
>> certificate data, but that's similar to wget/Firefox already since they just follow
>> the redirection. Doing that on my new development system results in an error about
>> SSL certificates which makes sense since I haven't been able to run make-ca because
>> of this problem yet.
>>
>> What makes me think that it's a problem with the URL redirection is that other
>> systems which have had make-ca installed already are now unable to get certificate
>> data updates as well, and they show the exact same log as above with the Mozilla/
>> DigiCert chain. The hg-edge.mozilla.org server does not appear to use the Mozilla
>> certificate root either as it's setup with LetsEncrypt, so just updating the URL
>> in / usr/sbin/make-ca does not work on new systems.
>>
>> To reproduce this, just run 'make-ca -g' on any system and it should fail.
>>
>> Can anyone else reproduce this? If so what should we do here?
>
> Confirmed.
>
> $ sudo make-ca -g
> Checking for new version of certdata.txt...done.
> Unable to get revision from server! Exiting.
I tried copying /etc/make-ca/make-ca.conf.dist to /etc/make-ca.conf and changing the
url from hg.mozilla.org to hg-edge.mozilla.org. But now I get the same error message.
I thought we were hosting a reformatted version on anduin. When I check there I see:
-rw-rw-r-- 1 apache lfsdev 6014 Apr 7 03:39 certdata.txt
Shouldn't make-ca be getting the data there?
-- Bruce
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page