Problems with make-ca on new and existing systems

"\"Douglas R. Reno\"" ([email protected] via blfs-dev Mailing List) <[email protected]>
Newsgroups gmane.linux.lfs.beyond.devel
Message-ID <[email protected]>
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?

- Doug

-- 
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.