I tested this patch now on 13-STABLE. It just works for me:

Guys, was written on the Bugzilla issue. I have verified this to work. I am still sufferting from this with py-requests. What can I do to move this forward to be included in 12.4?

In D31487#758826, @kevans wrote:

In D31487#720855, @1983-01-06_gmx.net wrote:

Is there anything I can do to make progress?

Hey, sorry. :-( I'm hoping I can find the energy to put into CA stuff going into the new year.

In that spirit, gitweb should be removed/moved as well. Regular users won't need it at all.

Is there anything I can do to make progress?

In D31487#710272, @kevans wrote:

So we really just need to decide what to do with CA_BUNDLE stuff, or understand what those ports do without it or if they can use the hashed store instead.

Question: Is this worth the effort given that 11.4 will be EOL in 1,5 months and all supported versions will have the root trust store installed by default?

Awesome to see this! Thank you Kyle.

In D26428#588146, @imp wrote:

In D26428#588030, @1983-01-06_gmx.net wrote:

You description is wrong. No BIOS will boot off an EFI partition. Don't mix BIOS and UEFI firmware implementation.

BIOS is the generic program that runs before the OS. UEFI is a kind of BIOS. This terminology pre-dates the IBM/PC and was used in CP/M and others.
CMS is what will never load a program from an ESP.

You description is wrong. No BIOS will boot off an EFI partition. Don't mix BIOS and UEFI firmware implementation.

In D26167#586261, @kevans wrote:

Excellent, thanks!

Would you prefer to receive attribution for this review at your phab email address (@gmx) or bugzilla (@siemens)?

Looks good for me now:

Comparing the fingerprint of the cert can be achived with OpenSSL using -fingerprint:

openssl x509 -sha1 -in cert.crt -noout -fingerprint

See https://www.openssl.org/docs/man1.1.1/man1/x509.html

I also see:

In D16857#525839, @kevans wrote:

In D16857#525790, @1983-01-06_gmx.net wrote:

Can someone tell me when this will land in RELEASE? I have jails running on 12.1-RELASE and can see that it is in STABLE only. 12.2-RELEASE?

Tentatively, the infrastructure has all been MFC'd to stable branches without any certs committed. I'm holding off on committing any certs to stable branches until I can test my freebsd-update addition in D21805 which seems to be requiring a little bit of a battle with freebsd-update-server.

Assuming I can figure that out in the next ~6-7 months, I'd like to ship 12.2-RELEASE with a bundle included. Since the original bundle was committed, we haven't had any that needed to be removed... I suspect that class of issue comes far enough apart that issuing SA for these just won't happen all that frequently.

Can someone tell me when this will land in RELEASE? I have jails running on 12.1-RELASE and can see that it is in STABLE only. 12.2-RELEASE?

In D16857#525229, @freebsd_oldach.net wrote:

In D16857#524898, @kevans wrote:

In D16857#524890, @1983-01-06_gmx.net wrote:

That all looks fine.

Here are now my questions:

1. Why has the hash option selected? D16352 uses the common approach to concat PEM files into one PEM bundle which can be easily transported and distributed.

I wasn't initially involved in this decision, but I find it more convenient to manually manage or identify what's being trusted as-is, since I can ls/grep around /etc/ssl/certs.

And of course it's a bit faster to just use the certificate hash as a selector into the file system instead of searching through a longish text file for a matching CA.

FWIW, sendmail (for example) has been expecting this since a long time.

As for curl, recompiling it w/o the CA_BUNDLE option gives:

As far as I can see when certs in are in base security/ca_root_nss seems to be obsolete for me, these ports need to be changed:

In D16857#524898, @kevans wrote:

In D16857#524890, @1983-01-06_gmx.net wrote:

That all looks fine.

Here are now my questions:

1. Why has the hash option selected? D16352 uses the common approach to concat PEM files into one PEM bundle which can be easily transported and distributed.

I wasn't initially involved in this decision, but I find it more convenient to manually manage or identify what's being trusted as-is, since I can ls/grep around /etc/ssl/certs.

Here is a test review from an huge enterprise user. I actually come from PR 160387 and D16352. I have been pointed to here by Helge Oldach.

I don't know how likely this is, but create_trusted_link may cause problems when you have two or more certs with the same subject. E.g., certs with overlapping validity dates. One expires, the other one starts one day before expiration of the former. You will overwrite those because you always assume .0. but it should be .0, .1, .2, and so forth (see https://docs.infor.com/ln/10.5/de-de/lnolh/help/tt/onlinemanual/https_soap_generate_hash.html). If you check "openssl s_client" with truss you'll see stuff like this

Here is a modified version for OpenSSL 1.0.2. These need to merged by checking the version of OpenSSL.

Folks, I took another step on this on a new machine with FreeBSD 12-STABLE by using OpenSSL from base, even with my changes it does not work. There is a misconception of openssl verify. Here it is used to verify the syntax of the input, but verify does verify the input syntactially and semantically against the root store on the system compiled into the OpenSSL objects. Our Siemens root is deemed to fail because it is selfsigned. This creates a chicken-and-egg situation. There is no switch to tell OpenSSL to syntactically verify the file, one has to apply a trick: openssl verify -no-CAfile -trusted ${i} ${i}.

After deinstallation I see this:

Let me run the script again and share the findings by Friday.

In D16352#352606, @feld wrote:

In D16352#350399, @1983-01-06_gmx.net wrote:

So I ran the snippet which perfoms openssl verify against company-internal CAs and I think that this might not really work. Here is our certificate listing. I wrote a simple Java tool which traverses the HTML code, downloads the certs in the physical order and writes them into a combined PEM file.

This does seem like a very unusual scenario. Siemens appears to have a very complicated internal CA root. I expect most people who have to get their servers to trust an internal CA are simply adding a single root CA certificate to the bundle; maybe two if they're dealing with two companies merging. I'm not sure how to approach this other than adding additional documentation to tell users how to structure their roots so it works nicely with ca-merge.

I have restructured my application by collecting roots and intermediates and then writing them and do now get:

So I ran the snippet which perfoms openssl verify against company-internal CAs and I think that this might not really work. Here is our certificate listing. I wrote a simple Java tool which traverses the HTML code, downloads the certs in the physical order and writes them into a combined PEM file.

Looks good to me.

Have you checked your script with: https://www.shellcheck.net/?

This looks quite nice, albeit I need to test this at work, I am trying to image how _merge_jks would work since this would require to have Java installed even for those do not have/use Java at all. Maybe a "-x keytool" would suffice to build the store?! What do you propose as path for cacerts? /usr/local/etc/ssl/cacerts?