Bug 256902
| Summary: | libfetch breaks usage of certctl(8) managed store when security/ca_root_nss is installed | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Michael Osipov <michael.osipov> | ||||||||||
| Component: | bin | Assignee: | Dag-Erling Smørgrav <des> | ||||||||||
| Status: | Closed FIXED | ||||||||||||
| Severity: | Affects Some People | CC: | bapt, delphij, driesm, emaste, eric.devolder, kevans, michael.osipov, se, tatsuki_makino | ||||||||||
| Priority: | --- | Flags: | des:
mfc-stable14+
des: mfc-stable13+ des: mfc-stable12+ |
||||||||||
| Version: | 12.2-STABLE | ||||||||||||
| Hardware: | Any | ||||||||||||
| OS: | Any | ||||||||||||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256923 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Michael Osipov
2021-06-30 11:53:25 UTC
fetch output: > root@deblndw013x:/usr/ports > # fetch -v https://deblndw011x.ad001.siemens.net/ > resolving server address: deblndw011x.ad001.siemens.net:443 > SSL options: 82004854 > Peer verification enabled > Using CA cert file: /usr/local/etc/ssl/cert.pem > Certificate verification failed for /C=DE/ST=Bayern/L=Muenchen/O=Siemens/serialNumber=ZZZZZZA1/OU=Siemens Trust Center/CN=Siemens Root CA V3.0 2016 > 34370727936:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915: > fetch: https://deblndw011x.ad001.siemens.net/: Authentication error > root@deblndw013x:/usr/ports > # SSL_CA_CERT_PATH=/etc/ssl/certs fetch -v https://deblndw011x.ad001.siemens.net/ > resolving server address: deblndw011x.ad001.siemens.net:443 > SSL options: 82004854 > Peer verification enabled > Using CA cert file: /usr/local/etc/ssl/cert.pem > Using CA cert path: /etc/ssl/certs > Verify hostname > TLSv1.3 connection established using TLS_AES_256_GCM_SHA384 > Certificate subject: /C=DE/O=Siemens/OU=LDA DW/CN=deblndw011x.ad001.siemens.net > Certificate issuer: /C=DE/ST=Bayern/L=Muenchen/O=Siemens/serialNumber=ZZZZZZB7/OU=Siemens Trust Center/CN=Siemens Issuing CA Intranet Server 2017 > requesting https://deblndw011x.ad001.siemens.net/ > remote size / mtime: 45 / 1623218965 > fetch.out 45 B 811 kBps 00s Anyone willing to go through this with me? My 12.4-STABLE has the following symlink mixed into /etc/ssl/certs. lrwxr-xr-x 1 root wheel - 53 Aug 9 08:14 cd8c0d63.0 -> ../../../usr/share/certs/trusted/AC_RAIZ_FNMT-RCM.pem lrwxr-xr-x 1 root wheel - 46 Aug 9 08:14 cd8c0d63.1 -> ../../../usr/local/share/certs/ca-root-nss.crt Aug 9 08:14 is the time I did one of installworld, delete-old or delete-old-libs. Does it have anything to do with this symlink to ca-root-nss.crt being made? (In reply to Tatsuki Makino from comment #3) Not necessarily the symlink, but the default path to the bundle from NSS libfetch uses. It is a misconception from the past which does not apply anymore with a truststore in base. (In reply to Michael Osipov from comment #4) I came back again with an understanding :) About this part, > if (ca_cert_file == NULL && > access(LOCAL_CERT_FILE, R_OK) == 0) > ca_cert_file = LOCAL_CERT_FILE; > if (ca_cert_file == NULL && > access(BASE_CERT_FILE, R_OK) == 0) > ca_cert_file = BASE_CERT_FILE; If there is a file that can be accessed by either BASE_CERT_FILE or LOCAL_CERT_FILE, it will not be possible to leave it to the default value of openssl. (In reply to Tatsuki Makino from comment #5) That is correct because: > 789 #define LOCAL_CERT_FILE "/usr/local/etc/ssl/cert.pem" > 790 #define BASE_CERT_FILE "/etc/ssl/cert.pem" The symlink is created by the port: https://github.com/freebsd/freebsd-ports/blob/86387d99797d313d96ddaf6e216285c87e5a9e1c/security/ca_root_nss/Makefile#L52-L55 (In reply to Michael Osipov from comment #6) That is to say that it will be solved with a turn off of option ETCSYMLINK. But it cannot be the default. This is because the symlink for security/openssl is also created there. However, I think its creation should be done on the security/openssl side. (There is a post of my similar statement on bug 248314 comment 15.) It looks like bug 269473 is actually trying to make changes regarding that. I think those reports should be considered integrated... (In reply to Tatsuki Makino from comment #7) I am aware of those and I also added a comment regarding them. Ultimately, the port maintainers should link to the system's truststore, that's it. Not a libfetch bug, please file bugs against the respective ports. (In reply to Dag-Erling Smørgrav from comment #9) I don't agree with that, I expect libfetch to use default store and not depend on the ports system and which port is installed. It clearly breaks the separation of base and ports especially because ca_root_nss sometimes comes as automatic port. (In reply to Dag-Erling Smørgrav from comment #9) libfetch needs to drop: https://github.com/freebsd/freebsd-src/blob/373ffc62c158e52cde86a5b934ab4a51307f9f2e/lib/libfetch/common.c#L1073-L1074 In my testing, libfetch successfully verifies certificates in FreeBSD 12, 13, 14, and 15 with and without ca_root_nss installed. If that is not the case for you, please provide a test case which can be reproduced outside of your corporate IT environment. (In reply to Dag-Erling Smørgrav from comment #12) I have described this in the title, as soon as ca_root_nss is installed (which I cannot control) and you have enterprise CA certs in your default store via certctl(8) libfetch will fail to verify the peer. Steps to reproduce: * Create a root CA with openssl * Create a CSR for a server * Process CSR with openssl and sign server cert * Use cert in server * Add that root CA to /etc/ssl/certs via certctl(8) * Issue a fetch request to that server * Watch fetch fail (In reply to Michael Osipov from comment #13) You can simplify if you want by just adding a self-signed server cert to the system trust store and rehash with certctl(8). If ca_root_nss, this cert won't visible. As soon as it is gone the default store will be picked up. Created attachment 245226 [details]
Git-formatted patch (main)
Created attachment 245227 [details]
Git-formatted patch (stable/14)
Created attachment 245228 [details]
Git-formatted patch (stable/13)
Created attachment 245229 [details]
Git-formatted patch (stable/12)
I have now attached a straight forward patch for all currently open branches. This changes nothing for users with internal URLs in terms of behavior, but simplifies life for users with custom CA certs in the system truststore. I've rewritten the commit message as:
libfetch: don't rely on ca_root_nss for certificate validation
Before certctl(8), there was no system trust store, and libfetch
relied on the CA certificate bundle from the ca_root_nss port to
verify peers.
We now have a system trust store and a reliable mechanism for
manipulating it (to explicitly add, remove, or revoke certificates),
but if ca_root_nss is installed, libfetch will still prefer that to
the system trust store.
With this change, unless explicitly overridden, libfetch will rely on
OpenSSL to pick up the default system trust store.
is that ok with you?
(In reply to Dag-Erling Smørgrav from comment #20) Yes, absolutely. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=09f5c1e118bb4eca77b83a0d08f559b20f60aa59 commit 09f5c1e118bb4eca77b83a0d08f559b20f60aa59 Author: Michael Osipov <michael.osipov@siemens.com> AuthorDate: 2023-10-03 05:53:20 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2023-10-03 05:53:20 +0000 libfetch: don't rely on ca_root_nss for certificate validation Before certctl(8), there was no system trust store, and libfetch relied on the CA certificate bundle from the ca_root_nss port to verify peers. We now have a system trust store and a reliable mechanism for manipulating it (to explicitly add, remove, or revoke certificates), but if ca_root_nss is installed, libfetch will still prefer that to the system trust store. With this change, unless explicitly overridden, libfetch will rely on OpenSSL to pick up the default system trust store. PR: 256902 MFC after: 3 days Reviewed by: kevans Differential Revision: https://reviews.freebsd.org/D42059 lib/libfetch/common.c | 8 -------- 1 file changed, 8 deletions(-) (In reply to commit-hook from comment #22) Fantastic, looking forward to MFC! Thank you! A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=fb058a9a40a5adc82721ed822fb4fba213446a7b commit fb058a9a40a5adc82721ed822fb4fba213446a7b Author: Michael Osipov <michael.osipov@siemens.com> AuthorDate: 2023-10-03 05:53:20 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2023-10-05 00:03:16 +0000 libfetch: don't rely on ca_root_nss for certificate validation Before certctl(8), there was no system trust store, and libfetch relied on the CA certificate bundle from the ca_root_nss port to verify peers. We now have a system trust store and a reliable mechanism for manipulating it (to explicitly add, remove, or revoke certificates), but if ca_root_nss is installed, libfetch will still prefer that to the system trust store. With this change, unless explicitly overridden, libfetch will rely on OpenSSL to pick up the default system trust store. PR: 256902 MFC after: 3 days Reviewed by: kevans Differential Revision: https://reviews.freebsd.org/D42059 (cherry picked from commit 09f5c1e118bb4eca77b83a0d08f559b20f60aa59) lib/libfetch/common.c | 8 -------- 1 file changed, 8 deletions(-) A commit in branch releng/14.0 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4357ae1174f37fa2c10f7de7c05536f23e7439c4 commit 4357ae1174f37fa2c10f7de7c05536f23e7439c4 Author: Michael Osipov <michael.osipov@siemens.com> AuthorDate: 2023-10-03 05:53:20 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2023-10-05 15:52:43 +0000 libfetch: don't rely on ca_root_nss for certificate validation Before certctl(8), there was no system trust store, and libfetch relied on the CA certificate bundle from the ca_root_nss port to verify peers. We now have a system trust store and a reliable mechanism for manipulating it (to explicitly add, remove, or revoke certificates), but if ca_root_nss is installed, libfetch will still prefer that to the system trust store. With this change, unless explicitly overridden, libfetch will rely on OpenSSL to pick up the default system trust store. PR: 256902 MFC after: 3 days Reviewed by: kevans Differential Revision: https://reviews.freebsd.org/D42059 Approved by: re (gjb) (cherry picked from commit 09f5c1e118bb4eca77b83a0d08f559b20f60aa59) (cherry picked from commit fb058a9a40a5adc82721ed822fb4fba213446a7b) lib/libfetch/common.c | 8 -------- 1 file changed, 8 deletions(-) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=baf69f6c997392cde9ae75d3ebc25a8201c7cc99 commit baf69f6c997392cde9ae75d3ebc25a8201c7cc99 Author: Michael Osipov <michael.osipov@siemens.com> AuthorDate: 2023-10-03 05:53:20 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2023-10-05 15:55:33 +0000 libfetch: don't rely on ca_root_nss for certificate validation Before certctl(8), there was no system trust store, and libfetch relied on the CA certificate bundle from the ca_root_nss port to verify peers. We now have a system trust store and a reliable mechanism for manipulating it (to explicitly add, remove, or revoke certificates), but if ca_root_nss is installed, libfetch will still prefer that to the system trust store. With this change, unless explicitly overridden, libfetch will rely on OpenSSL to pick up the default system trust store. PR: 256902 MFC after: 3 days Reviewed by: kevans Differential Revision: https://reviews.freebsd.org/D42059 (cherry picked from commit 09f5c1e118bb4eca77b83a0d08f559b20f60aa59) lib/libfetch/common.c | 8 -------- 1 file changed, 8 deletions(-) A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=8d939b7d98452c0357e49b090d5a685ea8a0e69a commit 8d939b7d98452c0357e49b090d5a685ea8a0e69a Author: Michael Osipov <michael.osipov@siemens.com> AuthorDate: 2023-10-03 05:53:20 +0000 Commit: Dag-Erling Smørgrav <des@FreeBSD.org> CommitDate: 2023-10-05 15:58:59 +0000 libfetch: don't rely on ca_root_nss for certificate validation Before certctl(8), there was no system trust store, and libfetch relied on the CA certificate bundle from the ca_root_nss port to verify peers. We now have a system trust store and a reliable mechanism for manipulating it (to explicitly add, remove, or revoke certificates), but if ca_root_nss is installed, libfetch will still prefer that to the system trust store. With this change, unless explicitly overridden, libfetch will rely on OpenSSL to pick up the default system trust store. PR: 256902 MFC after: 3 days Reviewed by: kevans Differential Revision: https://reviews.freebsd.org/D42059 (cherry picked from commit 09f5c1e118bb4eca77b83a0d08f559b20f60aa59) lib/libfetch/common.c | 8 -------- 1 file changed, 8 deletions(-) Thank you des@, at long last this is addressed. Looking forward to 13.3-RELEASE and 14-RELEASE. |
