Re: [openssl-users] scripting creating a cert
On 03/10/2017 01:10 AM, openssl-users-requ...@openssl.org digested: > Thing is that this then prompts for a number of fields: [...] > Is there some 'simple' way to provide these answers? Like with env > variables? Yes, and as others have already pointed out, there's also the possibility of command line parameters given to OpenSSL. A publicly available set of scripts that makes heavy use of the env var method and might serve as an example would be easyRSA (here, version 3): > # grep EASYRSA_REQ_ openssl-1.0.cnf > commonName_default = $ENV::EASYRSA_REQ_CN > countryName_default = $ENV::EASYRSA_REQ_COUNTRY > stateOrProvinceName_default = $ENV::EASYRSA_REQ_PROVINCE > localityName_default= $ENV::EASYRSA_REQ_CITY > 0.organizationName_default = $ENV::EASYRSA_REQ_ORG > organizationalUnitName_default = $ENV::EASYRSA_REQ_OU > commonName_default = $ENV::EASYRSA_REQ_CN > emailAddress_default= $ENV::EASYRSA_REQ_EMAIL > # grep EASYRSA_REQ_ easyrsa | grep -v ';;' > [ $EASYRSA_BATCH ] && opts="$opts -batch" || export > EASYRSA_REQ_CN="Easy-RSA CA" > [ ! $EASYRSA_BATCH ] && EASYRSA_REQ_CN="$1" > EASYRSA_REQ_CN="$name" > set_var EASYRSA_REQ_COUNTRY "US" > set_var EASYRSA_REQ_PROVINCE"California" > set_var EASYRSA_REQ_CITY"San Francisco" > set_var EASYRSA_REQ_ORG "Copyleft Certificate Co" > set_var EASYRSA_REQ_EMAIL m...@example.net > set_var EASYRSA_REQ_OU "My Organizational Unit" > set_var EASYRSA_REQ_CN ChangeMe https://github.com/OpenVPN/easy-rsa Kind regards, -- Jochen Bern Systemingenieur smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How many SAN entries...?
On 04/27/2017 04:09 PM, openssl-users-requ...@openssl.org digested: > From: "Blumenthal, Uri - 0553 - MITLL" <u...@ll.mit.edu> > > You do not "revoke" a subset of attributes aka SAN emails. When any of > the certified attributes changes (i.e., is certification no longer valid), > the certificate is revoked and (possibly) re-issued. Precisely. Now imagine the cert being used for S/MIME (why would a cert list several e-mail addresses if it weren't somehow related to e-mails and the addressee's identity?) and the CA or its procedures insisting on renewing keypairs when a new cert is issued. I'ld say you'ld get users and their pitchforks asking for multiple SINGLE-attribute/value certs real fast. Regards, -- Jochen Bern Systemingenieur Fon:+49 6151 9067-231 Fax:+49 6151 9067-290 E-Mail: jochen.b...@binect.de www.binect.de www.facebook.de/binect Binect ist ausgezeichnet: Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017 Binect GmbH Robert-Koch-Straße 9, 64331 Weiterstadt, DE Geschäftsführung: Christian Ladner, Dr. Frank Wermeyer, Nils Manegold Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 94685 Umsatzsteuer-ID: DE 221 302 264 MAX 21-Unternehmensgruppe ✁ Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser Nachricht durchzuführen. Wir schließen, außer für den Fall von Vorsatz oder grober Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch virenbefallene Software oder E-Mail aus. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly prohibited. All Binect GmbH emails are created thoroughly, nevertheless we do not accept any legal obligation for the information and wording contained herein. Binect GmbH has taken precautionary measures to reduce the risk of possible distribution of virus infected software or emails. However, we advise you to check attachments to this email for viruses. Except for cases of intent or gross negligence, we cannot accept any legal obligation for loss or damage by virus infected software. smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] How many SAN entries...?
On 04/26/2017 07:13 PM, Viktor Dukhovni was digested as writing:
> On Apr 26, 2017, at 1:03 PM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>
> wrote:
>> It?s been my understanding that a cert can contain as many SAN attributes as
>> needed,
>> but it appears that Apple believes it has to be only one (because
>> certificates with
>> more than one are not processed properly).
>
> Perhaps CAs have rarely issued email certificates with multiple email
> addresses.
The mechanics of verifying - or, if necessary, revoking - every single
one should be ... interesting. Unless, maybe, it's a boatload of
("typo"?) aliases from the same organization.
[Remembers manually splitting others' PGP pubkeys into single-user-ID
ones after signing parties so as to send every freshly-signed ID only to
the *one* address stated in it]
Regards,
--
Jochen Bern
Systemingenieur
Fon:+49 6151 9067-231
Fax:+49 6151 9067-290
E-Mail: jochen.b...@binect.de
www.binect.de
www.facebook.de/binect
Binect ist ausgezeichnet:
Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017
Binect GmbH
Robert-Koch-Straße 9, 64331 Weiterstadt, DE
Geschäftsführung: Christian Ladner, Dr. Frank Wermeyer, Nils Manegold
Unternehmenssitz: Weiterstadt
Register: Amtsgericht Darmstadt, HRB 94685
Umsatzsteuer-ID: DE 221 302 264
MAX 21-Unternehmensgruppe
✁
Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht
der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser
Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der
Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch
schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu
einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH
ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen,
um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu
minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf
alle Anhänge an dieser Nachricht durchzuführen.
Wir schließen, außer für den Fall von Vorsatz oder grober
Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch
virenbefallene Software oder E-Mail aus.
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of contents of this
e-mail is strictly prohibited. All Binect GmbH emails are created
thoroughly, nevertheless we do not accept any legal obligation for the
information and wording contained herein. Binect GmbH has taken
precautionary measures to reduce the risk of possible distribution of
virus infected software or emails. However, we advise you to check
attachments to this email for viruses. Except for cases of intent or
gross negligence, we cannot accept any legal obligation for loss or
damage by virus infected software.
smime.p7s
Description: S/MIME Cryptographic Signature
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Is there a "Golden" CA makefile?
On 04/29/2017 09:55 PM, John Lewis got digested: > I am looking for a CA makefile to use with a openvpn tutorial I am > writing https://github.com/Oflameo/openvpn_ws. Is there one officially > endorsed by the openssl project? Since you're specifically mentioning Open*VPN*, let me mention that EasyRSA is a spin-off of that project. Not makefiles based, and working with sub-CAs certainly isn't easy (though *possible* with version 3), but if you want to see how the OpenVPN people think "their" CAs *should* be run, that's what I'ld suggest to look at. In a more general sense, the policies and technical limitations of CAs vary too much for their operators to even agree on what color gold has, I guess ... (Not-quite-random example: Out of the box, OpenSSL dislikes CAs issuing same-DN certs with overlapping validity periods. OpenVPN, again out of the box, bases the mechanism of peer-specific configs on the CN. So if you want to renew the cert of some device you're managing remotely *through* the very VPN, you may(*) have an interest to *defeat* the OpenSSL behavior, so as to issue the new cert before the old one expires and saws off the branch you're adminning from. (*) Of course, there *are* other techniques to work around the problem, but.) Regards, -- Jochen Bern Systemingenieur Fon:+49 6151 9067-231 Fax:+49 6151 9067-290 E-Mail: jochen.b...@binect.de www.binect.de www.facebook.de/binect Binect ist ausgezeichnet: Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017 Binect GmbH Robert-Koch-Straße 9, 64331 Weiterstadt, DE Geschäftsführung: Christian Ladner, Dr. Frank Wermeyer, Nils Manegold Unternehmenssitz: Weiterstadt Register: Amtsgericht Darmstadt, HRB 94685 Umsatzsteuer-ID: DE 221 302 264 MAX 21-Unternehmensgruppe ✁ Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser Nachricht durchzuführen. Wir schließen, außer für den Fall von Vorsatz oder grober Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch virenbefallene Software oder E-Mail aus. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of contents of this e-mail is strictly prohibited. All Binect GmbH emails are created thoroughly, nevertheless we do not accept any legal obligation for the information and wording contained herein. Binect GmbH has taken precautionary measures to reduce the risk of possible distribution of virus infected software or emails. However, we advise you to check attachments to this email for viruses. Except for cases of intent or gross negligence, we cannot accept any legal obligation for loss or damage by virus infected software. smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Hardware client certificates moving to Centos 7
On 09/27/2017 10:10 PM, Michael Wojcik wrote: > On Behalf Of Jochen Bern > Sent: Wednesday, September 27, 2017 06:51 >> I don't know offhand which OpenSSL versions did away with MD5, but you >> *can* install an 0.9.8e (+ RHEL/CentOS backported security patches) >> straight off CentOS 7 repos > > Ugh. No need for 0.9.8e (which is from, what, the early Industrial > Revolution?). You and I would probably be willing to compile version $CURRENT_STABLE ourselves if needed, but then again, a dedicated CentOS 6 server would likely be fine with us as well. I presume that Stuart has an auditor breathing down his neck and itching to tick "current OS release of chosen standard distribs, only reputable / vendor repos configured, updates installed in regular intervals, no sources used or compilers installed, paid-support-request- and sue-for-damages forms prefilled in the drawer" checkboxes. Kind regards, -- Jochen Bern Systemingenieur www.binect.de smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Hardware client certificates moving to Centos 7
On 09/27/2017 02:07 PM, Stuart Marsden <stu...@myphones.com> wrote: > Is there a way a can install a version of openssl on a dedicated standalone > Centos 7 server which will support these phones? > That would be preferable to me than having to leave Centos 6 servers just > for this I don't know offhand which OpenSSL versions did away with MD5, but you *can* install an 0.9.8e (+ RHEL/CentOS backported security patches) straight off CentOS 7 repos: https://centos.pkgs.org/7/centos-x86_64/openssl098e-0.9.8e-29.el7.centos.3.x86_64.rpm.html (There's a 32bit version of the RPM, too, of course, if you need it.) Kind regards, -- Jochen Bern Systemingenieur www.binect.de smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
On 05/31/2018 03:03 PM, openssl-users-requ...@openssl.org distributed: > Date: Thu, 31 May 2018 18:45:02 +1000 > From: FooCrypt > > Place a teaspoon of fine grade white sand onto the skin of a snare drum Macroscopic hardware TRNGs are a *tad* yesteryear https://en.wikipedia.org/wiki/Lavarand because observing *quantum* random events doesn't require large devices https://en.wikipedia.org/wiki/Hardware_random_number_generator (not to mention being IIUC harder to influence by an attacker so as to make them lose randomness). Nonetheless, if you don't have the hardware (builtin TPM?) and cannot easily connect one to the given platform (as I suspect for the OP's architecture) ... For general computing platforms, I've taken to installing (and, of course, running and monitoring) haveged as a standard - on hosts *and* VMs. It can run in an AIS-31 test mode if you want to check out the entropy it collects. https://wiki.archlinux.org/index.php/Haveged >> On 31 May 2018, at 6:07 PM, chris.g...@kiffer.be wrote: >> I've also encountered this quite often, and I have a feeling that on >> today's connected devices there may be a lot of entropy "in the air" >> (quite literally) which is not being captured. Does any one know of >> research in this area? Not specifically for mobile phones or WiFi interfaces, if that's what you're referring to with "in the air". However, squeezing available entropy out of various less-than-predictable hardware and OS states is what *all* non-hardware entropy gatherers ultimately do, from the Linux kernel's /dev/random mechanisms to haveged to what-have-you. Regards, -- Jochen Bern Systemingenieur www.binect.de www.facebook.de/binect smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] PRNG is not seeded
On 06/06/2018 09:12 PM, openssl-users-requ...@openssl.org digestributed: > Date: Wed, 6 Jun 2018 16:12:59 + > From: Michael Wojcik > >> Hence my solution of using a hardware TRNG shared over the >> network with devices that lack the ability to have one added >> locally. > > Yes, I think that's a good approach. It reduces the attack surface, > since the client device can connect to the entropy-gathering device > with considerable assurance (it can be configured with a pinned CA > or PSK, etc), and at startup can use some entropy saved from the > previous run. An attacker in a privileged position could try active > attacks like a DoS against the connection to the entropy server, but > a (more dangerous) passive attack looks very difficult. Speaking of attack scenarios, I refreshed my info after this discussion and wondered how likely it is that someone (in a Linux world) would want to attack the entropy *sources* directly. A manipulated source's effect on applications (that read from /dev/random) would be somewhat limited due to the kernel folding in other sources as well (memento Linus' statement about RDRAND), and due to the fact that *many* consumers read from it (you cannot predict who gets which part of your manipulated entropy). For comparison, imagine someone attacking the kernel and manipulating the /dev/random driver so that it feeds predictable sequences to the targets (processes running executables "httpd", "gpg", etc.) but real pool data to all other consumers. Presto, a subverted system that still gets a clean bill of health from rngtest, ent, dieharder, or whatever other analyzer you care to try ... ... by which I mean to ask, since I read a quest for suitable entropy-distribution protocols between the lines here, maybe there is something to be said in favor of signed-at-source chunks of entropy being forwarded *through* the kernel unchanged, and leaving the trust-based selection of sources and final folding to the individual applications? > And it's practical for real-world data centers; implementation and > equipment costs are low. [has been trying to acquire a better *NTP* source than public unsigned servers in certain data centers for 8+ years] :-C Regards, -- Jochen Bern Systemingenieur www.binect.de www.facebook.de/binect smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL Cert serial number non-uniqueness impact
On 01/14/2018 12:07 PM, pratyush parimal wrote: > I read from several sources that the serial number of a cert MUST be > unique within a CA. But could someone explain what would happen if the > serial number was not unique? Certificate Revocation Lists (CRLs) identify invalid certificates by means of a) the CA keypair that issued it (the pubkey being represented in the signature) and b) the serial number, *not* pubkey / DN / ..., of the invalid cert. If that's not unique, revoking one of the affected certs will have the effect of revoking them all. Regards, -- Jochen Bern Systemingenieur www.binect.de smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Has client validated successfully?
On 02/20/2018 06:34 PM, J Decker <d3c...@gmail.com> wrote: > Yes that is true however here's the scenario. > Client does a verification and passes or fails, and via the SSL layer I can > query if the client validated the certificate. > If it failed, provide a option for the client to get a renewed certificate > for verification. If success, no action. > If an actor lies in this scenario he answers > lies *yes* and didn't, don't give him a means to actually verify. *noop* > lies *no* but did, then give him the root cert he already has *noop* > > so I don't have to trust the reply I'm willing to give him the right > root. That's nice from the server's POV, but the client REALLY REALLY SHOULD NOT install and/or put trust into any CA certs it received in-band in a connection that failed verification. The best (for you) it can do is to store it and offer it to its user for additional verification and *then* installation - and I'ld venture a guess that you'ld have to write such a client yourself. (And offering the *root* certificate isn't that far from the common practice of a server sending *most* of its CA chain in addition to its own certificate, anyway, so it's debatable whether you even *need* the result of the client's verification as an input to send the root as well.) Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Internal IP Exposed
On 03/25/2019 01:08 PM, openssl-users-requ...@openssl.org digested: > Date: Mon, 25 Mar 2019 11:33:55 +1100 > From: Abdul Qoyyuum > > GET /images HTTP/1.0 Note that this is a HTTP 1.*0* request that doesn't require the client to send a Host: header stating what *his* idea of "which server am I trying to talk to?" is. > HTTP/1.0 301 Moved Permanently > Location: https://10.240.123.1:10443/images/ /images is a directory, which means that the client is supposed to ask for "/images/" (with a trailing slash) to request a directory listing. The server is helpfully sending back a HTTP Redirect to tell the client what he *should* request instead, in the form of a complete URL, which necessitates a host and port part. Having no idea who and what the *client* expects to talk to, the server fills in what *it* knows - its local (internal) IP and port. This "attack" already worked that way almost 20 years ago, when I demonstrated it to some (horrified) bank IT people on their Netscape-based online banking solution middleware ... OpenSSL is not involved here, and whether (and what) you can do to close the gap depends on what HTTP server (and, if present, reverse proxy solution) you're using. Regards, -- Jochen Bern Systemingenieur www.binect.de www.facebook.de/binect smime.p7s Description: S/MIME Cryptographic Signature
Re: Remove All Software Generators
On 10/30/2019 04:19 PM, openssl-users-requ...@openssl.org digested: > From: Frederick Gotham > To: openssl-users@openssl.org > > I even tried deleting /dev/random and /dev/urandom ... don't do that. The Linux kernel is both a provider and a consumer of entropy, e.g., to randomize the TCP sequence numbers as it establishes TCP connections on behalf of applications. Unless you go all the way and add a TPM driver (as the only source of entropy) to *the kernel*, you risk ending up with "good crypto" on the application layer but easily hijacked connections, defeated stack randomization, SSH logins from remote that fail, etc. etc.. Kind regards, -- Jochen Bern Systemingenieur E jochen.b...@binect.de W www.binect.de
Re: How to rotate cert when only first matching cert been verified
On 23.12.20 23:56, openssl-users-requ...@openssl.org digested: > Message: 4 > Date: Wed, 23 Dec 2020 23:56:44 +0100 > From: David von Oheimb [...] > Yet since both your old and new server cert are not expired and have the > same subject, keyIdentifier, and serial number, > and you appended the new server cert to your list, it is no surprise > that the certificate chain building algorithm will pick up the old one. > For efficiency reasons, no other (equally applicable) certificates will > be tried. To expand on the "*should* you actually do it like this" angle: I do not see any reason why the new server cert (SC) should have *the same serial number* (SN) as the old one. At least in the general case - where the CA and the server are run by different entities -, the CA wants(*) to be able to revoke old and new SC separately, and CRLs identify revoked certs exclusively by the issuing CA Cert (CC) and the revoked cert's SN. So, what *is* the rationale to reuse the SN? Do you have a "verification" mechanism somewhere that (cannot be updated in a timely manner for the new SC and) would protest a changed SN, but *not* the changed validity period (or, for that matter, fingerprint or CA signature)? Note that the mere thought already makes me put quote marks around "verification" ... Disclaimer: I'm *not* saying that merely using different SNs will make the problem you're currently experiencing disappear. In fact, I consider that rather unlikely, but it might be one contributing factor. (*) Scenario 1: Before the old SC expires, the CA finds out that it issued a new SC to an imposter, so they now want to revoke the new but not the old. Scenario 2: The old SC is found to have been leaked after the new one was already issued, so at least the server admin would prefer to have the old SC revoked but *not* the new one. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature
Re: openssl-users Digest, Vol 73, Issue 29
On 25.12.20 00:35, openssl-users-requ...@openssl.org digested: > Message: 3 > Date: Fri, 25 Dec 2020 07:35:40 +0800 > From: ??? > > @Jochen actually, the certs have different SN, which indeed is not > consistent with the man doc. ... how so? Different certs having different SNs is what is supposed and most often *required* to happen, and what OpenSSL's "ca" command will actually do, so I'd be rather surprised if one of the man pages implied the opposite. Short of the user overriding OpenSSL defaults outright, of course. > below is my ca.crt file, I am not sure where it went wrong, maybe just my > wrong behavior? (For the records: *Different* keypair, SN, validity period (but see below), signature. *Identical* DNs, algos, keysizes, extension (one DNS SAN). *Self-signed* certs, no actual CA invoved. CN and SAN indicate "nsxmanager.pks.vmware.local", so it might play a role what kind of DNS (public or internal) is used while verifying an actual server. Validity periods of 10 years, but differ only by a shift of ~39h ... you're still *testing*, not fixing a legacy installation, right?) > Re post my code here, since I send it alone to Michael. I don't do actual *coding* (much), but this here: > After I compile curl with openssl backend, the new binary failed too. > > ./curl.openssl - -u admin:'Admin!23Admin' > https://nsxmanager.pks.vmware.local/api/v1/spec/vmware/types/Tag --cacert > ./ca.crt [...] > * SSL certificate problem: self signed certificate > * Closing connection 0 > curl: (60) SSL certificate problem: self signed certificate > More details here: https://curl.se/docs/sslcerts.html [...] suggests that it might play a role that you're working with *self-signed* certs ... As I said, I don't *code*, but the verify(1) command line tool shows the exact same behavior of only OKing the one out of your two certs that appears *first* in the CAfile: > $ openssl verify --CAfile TMP-AB TMP-A TMP-B > TMP-A: OK > C = US, ST = CA, L = Palo Alto, O = VMware, CN = nsxmanager.pks.vmware.local > error 18 at 0 depth lookup: self signed certificate > error TMP-B: verification failed > $ openssl verify --CAfile TMP-BA TMP-A TMP-B > C = US, ST = CA, L = Palo Alto, O = VMware, CN = nsxmanager.pks.vmware.local > error 18 at 0 depth lookup: self signed certificate > error TMP-A: verification failed > TMP-B: OK Whereas, when I throw in another, entirely *different* cert ... : > $ openssl verify --CAfile TMP-ABC TMP-C > TMP-C: OK So, yeah, it seems that OpenSSL dislikes seeing multiple partially-identical "CA" certs in a CAfile. Which doesn't surprise me quite *that* much, because I remember *stronger* adverse reactions to CAfiles where certs had identical DNs and overlapping(!) validity periods back in 2012. IIRC I also found docs saying that that was an officially unsupported scenario. Back then, I "fixed" the "problem" by appending A,B,C,... to the CN - which was possible because we're using *actual CAs* there. For server certs, where you need the CN to match the FQDN, you might want to add an OU with a timestamp so as to have the *DN* as a whole differ ... Kind regards, Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature
Re: CVE-2022-3602 and CVE-2022-3786 Critical OpenSSL 3.0.x security vulnerabilities
On 02.11.22 07:48, Turritopsis Dohrnii Teo En Ming wrote: I have 2 internet-facing CentOS 7.9 Linux servers in Europe. Are the patches available already? How do I patch OpenSSL on my CentOS 7.9 Linux servers? CentOS 7 does not come with 3.0 versions of OpenSSL. (Not even available from oft-used repos like EPEL, if I understand correctly, unlike with CentOS 8.) https://github.com/NCSC-NL/OpenSSL-2022/blob/main/software/README.md https://pkgs.org/search/?q=openssl If you installed it some other way, that "other way" would define how to install updates ... or cleanly uninstall it so as to install a current version from a different source. Kind regards, -- Jochen Bern Systemingenieur Binect GmbH smime.p7s Description: S/MIME Cryptographic Signature
