Re: [openssl-users] [EXTERNAL] Re: Self-signed error when using SSL_CTX_load_verify_locations CApath
> On Nov 30, 2018, at 7:33 PM, Sands, Daniel via openssl-users > wrote: > >> Viktor's points are all good ones, but considering how often this >> particular message causes confusion for users and developers (at >> least in my experience), I wonder whether changing the text to >> "Untrusted self-signed certificate in certificate chain" would help. >> That would suggest to the user that the problem might be an issue >> with the trust store. >> > My .02: The message "Self-signed certificate in certificate chain" > does make it sound like OpenSSL rejected the certificate precisely > because it's self signed, and not because it's an untrusted root > certificate. I would suggest a less misleading reason, at least. Are there compatibility concerns around changing error message text for which users may have created regex patterns in scripts? I agree the text could be better, but not sure in what releases if any to change the text, since the change may cause issues for some users. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [EXTERNAL] Re: Self-signed error when using SSL_CTX_load_verify_locations CApath
On Fri, 2018-11-30 at 23:55 +, Michael Wojcik wrote: > > "Self-signed certificate in certificate chain" does not to me > > > convey "No > > > certificate hash links" (or "CA certificate not found in hash > > > links"). > > > Viktor's points are all good ones, but considering how often this > particular message causes confusion for users and developers (at > least in my experience), I wonder whether changing the text to > "Untrusted self-signed certificate in certificate chain" would help. > That would suggest to the user that the problem might be an issue > with the trust store. > My .02: The message "Self-signed certificate in certificate chain" does make it sound like OpenSSL rejected the certificate precisely because it's self signed, and not because it's an untrusted root certificate. I would suggest a less misleading reason, at least. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath
> On Nov 30, 2018, at 7:25 PM, Charles Mills wrote: > > Well, it ought then to say "I couldn't find any certificates at all" rather > than "I found a self-signed certificate" when it did not. A self-signed certificate was found, in the chain being verified. The message should likely be more clear (perhaps along the lines suggested by Michael Wojcik), but it is not incorrect. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath
Well, it ought then to say "I couldn't find any certificates at all" rather than "I found a self-signed certificate" when it did not. I used to manage product developers. Sometimes I would point out a need for product improvement and they would say "the code doesn't work that way." I would reply "I understand. I'm asking you to change the code." Charles -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Friday, November 30, 2018 3:35 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath > On Nov 30, 2018, at 5:00 PM, Charles Mills wrote: > > "Self-signed certificate in certificate chain" does not to me convey "No certificate hash links" (or "CA certificate not found in hash links"). That's not really possible, because the code that's doing certificate validation works with an abstract certificate store API, and does not know whether a particular certificate should or should not have been listed a trust-anchor in some store. All we know is that we've reached a self-signed certificate in the chain (so no further issuers can be found) and it is not in any of the trust stores, so verification fails. Perhaps we could document the errors in a bit more depth, but I don't think it is possible to tell you that your CApath was missing some specific symlink. -- -- Viktor. -- 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
Re: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Viktor Dukhovni > Sent: Friday, November 30, 2018 16:35 > > > On Nov 30, 2018, at 5:00 PM, Charles Mills wrote: > > > > "Self-signed certificate in certificate chain" does not to me convey "No > > certificate hash links" (or "CA certificate not found in hash links"). > > That's not really possible, because the code that's doing certificate > validation works with an abstract certificate store API, and does not > know whether a particular certificate should or should not have been > listed a trust-anchor in some store. > > All we know is that we've reached a self-signed certificate in the > chain (so no further issuers can be found) and it is not in any > of the trust stores, so verification fails. > > Perhaps we could document the errors in a bit more depth, but I don't > think it is possible to tell you that your CApath was missing some > specific symlink. Viktor's points are all good ones, but considering how often this particular message causes confusion for users and developers (at least in my experience), I wonder whether changing the text to "Untrusted self-signed certificate in certificate chain" would help. That would suggest to the user that the problem might be an issue with the trust store. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath
> On Nov 30, 2018, at 5:00 PM, Charles Mills wrote: > > "Self-signed certificate in certificate chain" does not to me convey "No > certificate hash links" (or "CA certificate not found in hash links"). That's not really possible, because the code that's doing certificate validation works with an abstract certificate store API, and does not know whether a particular certificate should or should not have been listed a trust-anchor in some store. All we know is that we've reached a self-signed certificate in the chain (so no further issuers can be found) and it is not in any of the trust stores, so verification fails. Perhaps we could document the errors in a bit more depth, but I don't think it is possible to tell you that your CApath was missing some specific symlink. -- -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath
Thank you, yes, that solved it. May I respectfully suggest that you consider improving the error message? "Self-signed certificate in certificate chain" does not to me convey "No certificate hash links" (or "CA certificate not found in hash links"). Charles -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Friday, November 30, 2018 10:22 AM To: openssl-users@openssl.org Subject: Re: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath > On Nov 30, 2018, at 12:47 PM, Charles Mills wrote: > > I am using a client certificate that was signed by my “homegrown” CA (which > uses the OpenSSL utility). When I point to the CA .PEM with > SSL_CTX_load_verify_locations CAfile it works perfectly. When instead I use > CApath to point to a folder that contains only that one .PEM file it fails. See the documentation of c_rehash. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath
> On Nov 30, 2018, at 12:47 PM, Charles Mills wrote: > > I am using a client certificate that was signed by my “homegrown” CA (which > uses the OpenSSL utility). When I point to the CA .PEM with > SSL_CTX_load_verify_locations CAfile it works perfectly. When instead I use > CApath to point to a folder that contains only that one .PEM file it fails. See the documentation of c_rehash. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID
The way I understand the ECDSA standard, it is supposed to truncate the provided hash - which is why it is possible to have ECDSA-over-P256-SHA384. One possibility would be for you to truncate the SHA2 output yourself, IMHO. On 11/30/18, 12:36 PM, "openssl-users on behalf of Fuchs, Andreas" wrote: The problem is as follows: The digest parameter of the TPM2_Sign command is checked against the hash algorithms supported by the TPM. If the TPM only supports SHA256, then the maximum size for the digest parameter is 32 bytes. So you cannot pass in a SHA512 hash, even though the TPM does not even perform a hash operation. Kind of stupid, I know, but thats how it goes. For RSA, I could "emulate" signing by using the TPM2_RSA_Decrypt command. For ECDSA however there is no equivalent. Thus the tpm2-tss-engine will only support up to SHA384 (since that's what most TPMs support). Therefore, the engine needs to communicate to OpenSSL's TLS not to negotiate SHA512. That was apparently added für 1.0.1 and 1.1.1 recently as the ASN1_PKEY_CTRL_DEFAULT_MD_NID ameth ctrl. I just don't know enough about OpenSSL as to where to start with this. Anyone have any hints please ? From: William Roberts [bill.c.robe...@gmail.com] Sent: Friday, November 30, 2018 15:55 To: openssl-users@openssl.org Cc: Fuchs, Andreas Subject: Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas wrote: > > Hi all, > > I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine > The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg. What about when keys aren't restricted to one specific signing scheme and support raw encrypt/decrypt? You could just synthesize it by building up the signature structure on the client side and using the raw primitives to encrypt the signing structure directly. > > Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31 > > Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this. > Thus: Is the following approach correct ? > > So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328: > - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ? > - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ? > - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ? > - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ? > - Which one of the return codes (1 or 2) makes it mandatory rather than recommended ? > > Thanks a lot for any advice, > Andreas > -- > 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 smime.p7s Description: S/MIME cryptographic signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Self-signed error when using SSL_CTX_load_verify_locations CApath
(Apologies if a duplicate - I think I mis-sent the first attempt.) I wrote a TLS server application that runs under Windows and has been working successfully for years. I am currently using OpenSSL 1.1.0f. When I wrote the code I only supported a single CA file for client certificates. I pass the file name in through SSL_CTX_load_verify_locations CAfile and with CApath NULL. Recently I was asked to add support for multiple CA files. I updated my parameter handling to support a CA path, and I can now pass the path instead using SSL_CTX_load_verify_locations CApath. I am using a client certificate that was signed by my "homegrown" CA (which uses the OpenSSL utility). When I point to the CA .PEM with SSL_CTX_load_verify_locations CAfile it works perfectly. When instead I use CApath to point to a folder that contains only that one .PEM file it fails. My verify callback is driven with -Error with certificate at depth: 1 err 19:self signed certificate in certificate chain error:1417C086:SSL routines:tls_process_client_certificate:certificate verify failed:ssl\statem\statem_srvr.c:2893: Yes, the CA certificate is a root certificate and is self-signed. But it works as a CAfile. Can someone give me some guidance here? FWIW I specify SSL_CTX_set_verify(sslContext, SSL_VERIFY_PEER, verify_callback); Thanks, Charles -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID
The problem is as follows: The digest parameter of the TPM2_Sign command is checked against the hash algorithms supported by the TPM. If the TPM only supports SHA256, then the maximum size for the digest parameter is 32 bytes. So you cannot pass in a SHA512 hash, even though the TPM does not even perform a hash operation. Kind of stupid, I know, but thats how it goes. For RSA, I could "emulate" signing by using the TPM2_RSA_Decrypt command. For ECDSA however there is no equivalent. Thus the tpm2-tss-engine will only support up to SHA384 (since that's what most TPMs support). Therefore, the engine needs to communicate to OpenSSL's TLS not to negotiate SHA512. That was apparently added für 1.0.1 and 1.1.1 recently as the ASN1_PKEY_CTRL_DEFAULT_MD_NID ameth ctrl. I just don't know enough about OpenSSL as to where to start with this. Anyone have any hints please ? From: William Roberts [bill.c.robe...@gmail.com] Sent: Friday, November 30, 2018 15:55 To: openssl-users@openssl.org Cc: Fuchs, Andreas Subject: Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas wrote: > > Hi all, > > I'm currently implementing a TPM2 engine for OpenSSL over at > https://github.com/tpm2-software/tpm2-tss-engine > The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA > from my engine with any hash alg, even though the TPM's keys are restricted > to just one specific hash alg. What about when keys aren't restricted to one specific signing scheme and support raw encrypt/decrypt? You could just synthesize it by building up the signature structure on the client side and using the raw primitives to encrypt the signing structure directly. > > Most recently, David Woodhouse pointed out the possibility to require a > certain hash-alg from the key to TLS via the ameth > ASN1_PKEY_CTRL_DEFAULT_MD_NID at > https://github.com/tpm2-software/tpm2-tss-engine/issues/31 > > Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm > following the right path for implementing this. > Thus: Is the following approach correct ? > > So, at > https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328: > - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const > EVP_PKEY *pkey)" to get the ameth ? > - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, > (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ? > - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, > void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ? > - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the > provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = > NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ? > - Which one of the return codes (1 or 2) makes it mandatory rather than > recommended ? > > Thanks a lot for any advice, > Andreas > -- > 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
Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID
On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas wrote: > > Hi all, > > I'm currently implementing a TPM2 engine for OpenSSL over at > https://github.com/tpm2-software/tpm2-tss-engine > The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA > from my engine with any hash alg, even though the TPM's keys are restricted > to just one specific hash alg. What about when keys aren't restricted to one specific signing scheme and support raw encrypt/decrypt? You could just synthesize it by building up the signature structure on the client side and using the raw primitives to encrypt the signing structure directly. > > Most recently, David Woodhouse pointed out the possibility to require a > certain hash-alg from the key to TLS via the ameth > ASN1_PKEY_CTRL_DEFAULT_MD_NID at > https://github.com/tpm2-software/tpm2-tss-engine/issues/31 > > Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm > following the right path for implementing this. > Thus: Is the following approach correct ? > > So, at > https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328: > - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const > EVP_PKEY *pkey)" to get the ameth ? > - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, > (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ? > - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, > void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ? > - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the > provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = > NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ? > - Which one of the return codes (1 or 2) makes it mandatory rather than > recommended ? > > Thanks a lot for any advice, > Andreas > -- > 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
Re: [openssl-users] What is the need for 0x00 byte prefix in pubkey and prime of a static DH key pair?
The DER (Distinguished Encoding Rules of ASN.1, which can be found in ITU-T recommendation X.680 and X.681) requirement is that if a particular number is positive, the highest-order bit can never be set (since the highest-order bit is always the negative sign indicator). The rules further explain that the appropriate way to encode a positive integer with the highest bit set is to add an additional 0x00 byte, making the new most significant bit into a 0. This is also why the serial number field in a certificate can be 21 bytes long, even when implementing PKIX's minimum serial number length of 20 bytes. Numbers included in an ASN.1-encoded structure aren't ever intended to be used directly, they're intended to be decoded before the data is passed back to client code. I realize this is much more information than you asked, but it might help to think of it as "it's done this way for compliance with the standards". -Kyle H On Thu, Nov 29, 2018, 21:26 M K Saravanan Hi, > > When I create static DH key pair using openssl, why the public key and > prime contains the prefix 0x00 byte? > > For e.g. in 1024 bit key, 128 bytes is enough. > > private key properly shows 128 bytes. But public key and prime shows > 129 bytes with a 0x00 byte at the beginning. What is the need for > this 0x00 byte at the beginning? i.e. why it is using 129 bytes > instead of 128? > > > $ openssl version > OpenSSL 1.1.1 11 Sep 2018 > > $ openssl dhparam -out mydhp.pem 1024 > [...] > > $ openssl genpkey -paramfile ./mydhp.pem -out mydhkey.pem > > $ openssl pkey -in ./mydhkey.pem -text -noout > DH Private-Key: (1024 bit) > private-key: > 52:61:87:52:b4:27:5f:c3:cf:ab:2f:20:b4:aa:b7: > df:c3:87:63:50:d2:06:dd:65:8f:db:55:2e:08:d5: > 62:44:1a:f5:d8:73:66:fe:a7:c4:43:be:f7:f0:d0: > ba:4c:bf:f0:70:70:c9:25:92:da:ef:69:01:1a:b9: > d9:d9:1f:b9:22:a6:84:48:d8:58:a8:a4:9e:7f:85: > 6b:9e:45:89:07:0c:fb:00:f1:0a:fb:24:10:e4:bb: > 2b:1c:7d:dc:d1:12:a3:21:5a:9b:8e:bf:9d:33:e8: > 65:fe:c2:5c:ea:47:fa:00:04:80:cf:85:e1:c6:71: > 67:4b:7b:71:92:07:59:48 > public-key: > 00:a0:0d:41:8a:27:55:07:2a:01:dd:a7:e2:86:bb: > 69:71:86:1d:62:0c:f3:b7:61:78:81:37:6c:a1:d3: > e8:55:9d:8a:1f:e8:5e:7f:18:00:0f:4e:1d:97:70: > a0:e7:19:2b:82:69:c3:aa:61:ea:b8:9c:10:36:19: > e9:b9:13:db:9a:ef:34:bf:10:f7:93:84:5d:a3:b4: > 58:3a:40:ec:4b:79:06:52:b8:fe:b8:22:0d:f3:f9: > 33:1e:8e:43:69:bb:77:3d:10:78:c6:65:e8:04:08: > 96:1e:cc:6c:92:e4:55:f4:2c:d0:3d:b7:5f:58:70: > cf:fe:a7:5f:23:e3:d9:5e:c4 > prime: > 00:a2:f4:9d:1c:3f:75:8f:3e:e3:c9:95:09:79:09: > 16:f2:f0:61:c4:e1:b9:23:22:a3:58:d7:38:7d:06: > af:57:ad:14:5e:13:bd:71:ed:31:89:cb:65:d6:46: > 3b:29:57:ad:a9:8e:58:e6:df:c0:37:2f:4f:be:45: > d7:c8:f1:87:ef:af:65:87:34:4a:7d:78:b8:0b:0b: > 33:d8:c1:fb:05:9e:ce:9a:27:7e:4a:2a:aa:18:33: > 35:ea:d0:b0:b7:fa:cb:d1:51:bf:11:98:12:24:be: > 1d:1c:87:c3:37:ed:0f:b9:53:23:fc:a1:be:75:ed: > 81:04:e5:6a:b3:83:40:e0:43 > generator: 2 (0x2) > > > with regards, > Saravanan > -- > 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
Re: [openssl-users] What is the need for 0x00 byte prefix in pubkey and prime of a static DH key pair?
On 30/11/2018 05:26, M K Saravanan wrote: > Hi, > > When I create static DH key pair using openssl, why the public key and > prime contains the prefix 0x00 byte? Because otherwise those numbers would be treated as negative (due to the most significant bit being set) which is incorrect. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
