Page MenuHomeFreeBSD

1983-01-06_gmx.net (Michael Osipov)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 19 2018, 5:53 PM (114 w, 6 d)

Recent Activity

Tue, Sep 15

1983-01-06_gmx.net added a comment to D26428: Initial support for implementing the bootXXX.efi workaround.
In D26428#588146, @imp 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.

Tue, Sep 15, 3:52 PM
1983-01-06_gmx.net commandeered D26428: Initial support for implementing the bootXXX.efi workaround.

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

Tue, Sep 15, 6:30 AM

Wed, Sep 9

1983-01-06_gmx.net added a comment to D26167: certctl: fix hashed link generation with duplicate subjects.

Excellent, thanks!

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

Wed, Sep 9, 8:26 AM
1983-01-06_gmx.net accepted D26167: certctl: fix hashed link generation with duplicate subjects.

Looks good for me now:

Wed, Sep 9, 6:19 AM

Tue, Sep 8

1983-01-06_gmx.net added a comment to D26167: certctl: fix hashed link generation with duplicate subjects.

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

Tue, Sep 8, 6:20 AM

Mon, Sep 7

1983-01-06_gmx.net requested changes to D26167: certctl: fix hashed link generation with duplicate subjects.

I also see:

Mon, Sep 7, 1:46 PM

Mar 2 2020

1983-01-06_gmx.net added a comment to D16857: Introduce certctl(8).

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.

Mar 2 2020, 7:21 PM
1983-01-06_gmx.net added a comment to D16857: Introduce certctl(8).

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?

Mar 2 2020, 1:16 PM

Feb 29 2020

1983-01-06_gmx.net added a comment to D16857: Introduce certctl(8).

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.

Feb 29 2020, 1:28 PM

Feb 28 2020

1983-01-06_gmx.net added a comment to D16857: Introduce certctl(8).

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

Feb 28 2020, 2:06 PM
1983-01-06_gmx.net added a comment to D16857: Introduce certctl(8).

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:

Feb 28 2020, 2:01 PM
1983-01-06_gmx.net added a comment to D16857: Introduce certctl(8).

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.

Feb 28 2020, 1:57 PM
1983-01-06_gmx.net added a comment to D16857: Introduce certctl(8).

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.

Feb 28 2020, 1:13 PM
1983-01-06_gmx.net reopened D16857: Introduce certctl(8).

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

Feb 28 2020, 12:25 PM

Feb 25 2019

1983-01-06_gmx.net added a comment to D16352: security/ca_root_nss: Add a ca-merge utility to permit including private CAs.

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

Feb 25 2019, 3:59 PM
1983-01-06_gmx.net added a comment to D16352: security/ca_root_nss: Add a ca-merge utility to permit including private CAs.

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}.

Feb 25 2019, 3:33 PM

Oct 1 2018

1983-01-06_gmx.net requested changes to D16352: security/ca_root_nss: Add a ca-merge utility to permit including private CAs.

After deinstallation I see this:

Oct 1 2018, 11:56 AM

Sep 12 2018

1983-01-06_gmx.net added a comment to D16352: security/ca_root_nss: Add a ca-merge utility to permit including private CAs.

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

Sep 12 2018, 2:35 PM

Aug 5 2018

1983-01-06_gmx.net added a comment to D16352: security/ca_root_nss: Add a ca-merge utility to permit including private CAs.
In D16352#352606, @feld 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.

Aug 5 2018, 5:50 PM

Jul 30 2018

1983-01-06_gmx.net added a comment to D16352: security/ca_root_nss: Add a ca-merge utility to permit including private CAs.

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

Jul 30 2018, 3:51 PM
1983-01-06_gmx.net added a comment to D16352: security/ca_root_nss: Add a ca-merge utility to permit including private CAs.

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.

Jul 30 2018, 2:33 PM
1983-01-06_gmx.net added inline comments to D16352: security/ca_root_nss: Add a ca-merge utility to permit including private CAs.
Jul 30 2018, 9:44 AM
1983-01-06_gmx.net accepted D16499: www/tomcat[6|7|8]: Bring improvements from Tomcat[85|9].

Looks good to me.

Jul 30 2018, 9:42 AM

Jul 19 2018

1983-01-06_gmx.net added a comment to D16352: security/ca_root_nss: Add a ca-merge utility to permit including private CAs.

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

Jul 19 2018, 6:32 PM
1983-01-06_gmx.net requested changes to D16352: security/ca_root_nss: Add a ca-merge utility to permit including private CAs.

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?

Jul 19 2018, 6:26 PM