Re: [openssl-users] SSL_CTX_load_verify_locations only with CAPath
Is "surprising" a better word than sub-optimal? If you and Dave didn't know about it (nor did I) then it's surprising. And therefore probably not a good thing. Yes it can be useful. But the openssl "rehash" program only read one PEM block per file. So we need to fix one of those things. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_CTX_load_verify_locations only with CAPath
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Salz, Rich
> Sent: Tuesday, July 07, 2015 08:36
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] SSL_CTX_load_verify_locations only with
> CAPath
>
> > I thought, as the doc has (always? long?) said, that CApath must have each
> > cert (or CRL) in a separate file. But on checking I see that by_dir.c
> > actually
> calls
> > X509_load_{cert,crl}_file from by_file.c, which for PEM loads all certs (or
> crls)
> > in a file to the working context. Thus a hashlink to only the 3rd cert in a
> > file,
> > where that 3rd cert is the only one you need, actually works even though
> not
> > documented and I'm not sure intended.
>
> That's definitely sub-optimal. Can you open a ticket for this?
Is it? It could be useful - you could have multiple certificates in one or more
files in the certificate directory, and make multiple hash links (hard or
symbolic, on filesystems where those are both options) to that physical file. I
can see use cases for that. At the very least, it saves extracting all the
certificates from a PEM file when creating the certificate directory, if you
use a script that gets the hash value of each certificate in the file.
I personally don't much care, but I could believe that someone else might find
that useful.
--
Michael Wojcik
Technology Specialist, Micro Focus
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_CTX_load_verify_locations only with CAPath
> I thought, as the doc has (always? long?) said, that CApath must have each
> cert (or CRL) in a separate file. But on checking I see that by_dir.c
> actually calls
> X509_load_{cert,crl}_file from by_file.c, which for PEM loads all certs (or
> crls)
> in a file to the working context. Thus a hashlink to only the 3rd cert in a
> file,
> where that 3rd cert is the only one you need, actually works even though not
> documented and I'm not sure intended.
That's definitely sub-optimal. Can you open a ticket for this?
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_CTX_load_verify_locations only with CAPath
After downloading the root certificate GlobalSignRootCA.crt and installing it
in the folder with its appropriate hash everything worked fine. Thanks for your
suggestion.
-.wikipedia.org is the end user certificate, right?
-Ursprüngliche Nachricht-
Von: openssl-users [mailto:openssl-users-boun...@openssl.org] Im Auftrag von
David Thompson
Gesendet: Dienstag, 7. Juli 2015 04:57
An: openssl-users@openssl.org
Betreff: Re: [openssl-users] SSL_CTX_load_verify_locations only with CAPath
> From: openssl-users On Behalf Of Dr. Roger Cuypers
> Sent: Monday, July 06, 2015 10:43
> Follow up:
>
> For some reason, the X509_NAME_hash function calculates a very
> different hash for the server certificate:
>
> 5ad8a5d6
>
> Renaming the certificate to 5ad8a5d6.0 causes it to be found, but I
> wonder where the difference in the hashes lies.
>
[reformatted]
> openssl x509 -in D:\certs\-.wikipedia.org.crt -out
> D:\certs\-.wikipedia.org.der -outform DER openssl x509 -in
> D:\certs\-.wikipedia.org.der -inform DER -out
> D:\certs\-.wikipedia.org.pem -outform PEM
Aside: those first two steps accomplish nothing; -.wikipedia.org.crt was
already PEM (we know it worked in CAfile). 'x509' reads PEM by default.
> openssl x509 -in D:\certs\-
> .wikipedia.org.pem -noout -subject_hash
> 690deae8
>
> Then in D:\certs:
>
> D:\certs>mklink /h 690deae8.0 -.wikipedia.org.pem
>
I bet you put the entire cert *chain* in the -.wikipedia.org.crt file.
The leaf cert (currently) used by wikipedia, with subject=
/C=US/ST=California/L=San Francisco/O=Wikimedia Foundation,
Inc./CN=*.wikipedia.org issuer= /C=BE/O=GlobalSign nv-sa/CN=GlobalSign
Organization Validation CA - SHA256 - G2
serial=1121972E32A5E5B2E29D472DFEDB72D6276E
notBefore=Dec 16 21:24:03 2014 GMT
notAfter=Feb 19 12:00:00 2017 GMT
has subject hash 690deae8.
This cert is sent from the server. It is not looked up in the truststore and
does not need to be in the truststore; if it is that copy is ignored.
The *root* cert for that wikipedia chain is subject= issuer= /C=BE/O=GlobalSign
nv-sa/OU=Root CA/CN=GlobalSign Root CA
serial=0401154B5AC394
notBefore=Sep 1 12:00:00 1998 GMT
notAfter=Jan 28 12:00:00 2028 GMT
and this has subject hash 5ad8a5d6. This is the only cert that needs to be or
is looked up in the truststore, and thus for CApath needs correct hash.
I thought, as the doc has (always? long?) said, that CApath must have each cert
(or CRL) in a separate file. But on checking I see that by_dir.c actually calls
X509_load_{cert,crl}_file from by_file.c, which for PEM loads all certs (or
crls) in a file to the working context. Thus a hashlink to only the 3rd cert in
a file, where that 3rd cert is the only one you need, actually works even
though not documented and I'm not sure intended.
THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are
proprietary and confidential information protected from disclosure and intended
only for the use of the recipient(s) named above. If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified that
any dissemination, distribution or copying of this message or any attachments
is strictly prohibited. If you have received this communication in error,
please notify CardConnect immediately by replying to this message and then
delete this message and any attachments from your computer.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Forthcoming OpenSSL releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2d and 1.0.1p. These releases will be made available on 9th July. They will fix a single security defect classified as "high" severity. This defect does not affect the 1.0.0 or 0.9.8 releases. Yours The OpenSSL Project Team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVmpufAAoJEAEKUEB8TIy9yVAIALIZcV/4IW2ab7ENffcThFcz Wlgr553L2bciqRYU99EK8w+4Peg54lKoVw/5rZOQmL4fZqS9jAV+76PNz1kQX4jM 2+oe+F6Ed9A4GgwYbh69WDzSnnIdImH5aa1ui2AOqsgsT0aCZkups0hexCqKFSCW e5+OlHXA6FXNzsvRUTzcvfQBczakM7Z/7V4pOpTouzCwHQ+O1jriDRuI+8TVaF0w HpFWJ5uTGfY2lP3p1xI/A+11jfoxTd/XW7ljpqybTx7xARzH7tIuWQk+5Qd7DOZP NEdKw1YtPTXOR3MZJc4xShxv5SWFBjqUjmtVkHpF/dFmBWaMWTDYfAMhk/WOyAQ= =yVBV -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] [openssl-announce] Forthcoming OpenSSL releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2d and 1.0.1p. These releases will be made available on 9th July. They will fix a single security defect classified as "high" severity. This defect does not affect the 1.0.0 or 0.9.8 releases. Yours The OpenSSL Project Team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVmpufAAoJEAEKUEB8TIy9yVAIALIZcV/4IW2ab7ENffcThFcz Wlgr553L2bciqRYU99EK8w+4Peg54lKoVw/5rZOQmL4fZqS9jAV+76PNz1kQX4jM 2+oe+F6Ed9A4GgwYbh69WDzSnnIdImH5aa1ui2AOqsgsT0aCZkups0hexCqKFSCW e5+OlHXA6FXNzsvRUTzcvfQBczakM7Z/7V4pOpTouzCwHQ+O1jriDRuI+8TVaF0w HpFWJ5uTGfY2lP3p1xI/A+11jfoxTd/XW7ljpqybTx7xARzH7tIuWQk+5Qd7DOZP NEdKw1YtPTXOR3MZJc4xShxv5SWFBjqUjmtVkHpF/dFmBWaMWTDYfAMhk/WOyAQ= =yVBV -END PGP SIGNATURE- ___ openssl-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
