From felipe at felipegasper.com Fri Oct 1 01:28:17 2021 From: felipe at felipegasper.com (Felipe Gasper) Date: Thu, 30 Sep 2021 21:28:17 -0400 Subject: LE/DST expired root: workaround #2 Message-ID: Hello, https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ ^^ This document indicates that, by enabling trusted-first mode, I should be able to work around the LE expiration problem. I?m either misunderstanding this or ?holding it wrong?, though, because I can?t see that setup making any difference. I?ve got a chain with: 1) leaf cert (felipegasper.com) 2) Let?s Encrypt R3 3) ? and the cert called ?ISRG Root X1? that is *not*, in fact, a root cert Cert #3 in the above is issued by the now-expired ?DST Root CA X3?, so including it (understandably) ?misleads? `openssl verify` into looking into its root store for that cert?s issuer, which causes a verification failure. I notice, though, that connection handshakes succeed despite the non-self-signed ?ISRG Root X1? being part of the sent chain. Is there a way I can make `openssl verify` behave the same way as connection handshakes? So the 3 certs I have in my chain will pass OpenSSL?s dedicated verification logic? Thank you! cheers, -Felipe Gasper From tomas at openssl.org Fri Oct 1 07:26:24 2021 From: tomas at openssl.org (Tomas Mraz) Date: Fri, 01 Oct 2021 09:26:24 +0200 Subject: LE/DST expired root: workaround #2 In-Reply-To: References: Message-ID: On Thu, 2021-09-30 at 21:28 -0400, Felipe Gasper wrote: > Hello, > > ???????? > https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ > > ^^ This document indicates that, by enabling trusted-first mode, I > should be able to work around the LE expiration problem. > > I?m either misunderstanding this or ?holding it wrong?, though, > because I can?t see that setup making any difference. > > I?ve got a chain with: > 1) leaf cert (felipegasper.com) > 2) Let?s Encrypt R3 > 3) ? and the cert called ?ISRG Root X1? that is *not*, in fact, a > root cert > > Cert #3 in the above is issued by the now-expired ?DST Root CA X3?, > so including it (understandably) ?misleads? `openssl verify` into > looking into its root store for that cert?s issuer, which causes a > verification failure. > > I notice, though, that connection handshakes succeed despite the non- > self-signed ?ISRG Root X1? being part of the sent chain. > > Is there a way I can make `openssl verify` behave the same way as > connection handshakes? So the 3 certs I have in my chain will pass > OpenSSL?s dedicated verification logic? You need to have a self-signed ISRG Root X1 as a trusted cert in the openssl verify. That self-signed ISRG Root X1 is contained in up-to- date OS certificate trust stores so that's the reason why connections succeed (with 1.0.2 in case the -trusted_first is used). The 1.1.x or 1.0.2 will ignore the non-self-signed ISRG Root X1 certificate and use the self-signed ISRG Root X1 to verify the Let's Encrypt R3 intermediate cert. However 1.0.2 without -trusted_first will always try to verify the path via the non-self-signed ISRG Root X1 which leads to the expired DST Root CA X3 cert in the trust store which then fails the verification. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From alexandre.robuchon at gmail.com Sat Oct 2 15:24:26 2021 From: alexandre.robuchon at gmail.com (Alex Robuchon) Date: Sat, 2 Oct 2021 17:24:26 +0200 Subject: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate ) Message-ID: Hello Openssl community, I've encountered an issue with em-http-request ( https://github.com/igrigorik/em-http-request) based on top of eventmachine ( https://github.com/eventmachine/eventmachine) since let's encrypt Root certificate expired the 30th of September. The project has a callback function registered with SSL_CTX_set_verify and failed to verify DST Root CA X3 since it expired. >From what I understood about the let's encrypt certificate chain, R3 is cross signed and two chained could be built: - leaf <- R3 <- ISRG Root X1 <- DST Root CA X3 (self-signed) - leaf <- R3 <- ISRG Root X1 (self-signed) The servers by default return the first chain but from what I understand depending on the openssl version/flags it should use the second path if ISRG Root X1 is in the store My config : openssl version : OpenSSL 1.1.1f 31 Mar 2020 os : 5.8.0-63-generic #71-Ubuntu SMP Tue Jul 13 15:59:12 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux ISRG Root X1 self signed is in my cert store. So from what I understand, trusted first is default in this version of openssl and the second path should be taken. For the record s_client can valide the second path on my machine : $ echo | openssl s_client -connect retouche-pro.ch:443 -name retouche-pro.ch -servername retouche-pro.ch CONNECTED(00000003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = retouche-pro.ch verify return:1 --- Certificate chain 0 s:CN = retouche-pro.ch i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 --- So I suppose the problem relies on the use of openssl in the ruby libs. However what I'm a bit surprised with is the fact that SSL_CTX_set_verify is called with the "wrong" certificate chain. The documentation says it's going to be called for each certificate in the chain but do not specify if it's the chain specified by the server or the one built by openssl with trusted first algorithm. I also tried adding a verify callback on the ruby net http library ( https://github.com/ruby/net-http) which is passed to SSL_CTX_set_verify under the hood and I also noticed that it's using the "wrong" chain. Is it normal to have the callback defined in SSL_CTX_set_verify to be called with the wrong chain ? Or do you think something is not configured correctly on these gems ? If it's normal behavior how can I have additional certificate verification on the trusted first chain. Thanks for reading, I hope it was not too boring or confusing. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.cudbardb at freeradius.org Sat Oct 2 16:19:04 2021 From: a.cudbardb at freeradius.org (Arran Cudbard-Bell) Date: Sat, 2 Oct 2021 11:19:04 -0500 Subject: Use of ossl_unused in err.h.in Message-ID: <6FDEA5D3-4869-4AF1-8EA0-D714D0EAB205@freeradius.org> In current master HEAD and 3.0.0 calling ERR_GET_REASON throws the following warning: src/lib/tls/session.c:1323:43: warning: 'ERR_GET_REASON' was marked unused but was used [-Wused-but-marked-unused] while ((ssl_err = ERR_peek_error()) && (ERR_GET_REASON(ssl_err) == BIO_R_UNSUPPORTED_METHOD)) { This is because the static inline functions in include/openssl/err.h.in have been marked up with ossl_unused i.e. (__attribute__((unused))). I'm not sure what compiler the OP of https://github.com/openssl/openssl/issues/12792 was using, but it should not be generating a -Wunused-function for a static inline function in a header file. These are by their nature public functions, and should not generate unused function warnings. The only correct place to generate this warnings is when the functions's visibility is limited to the compilation unit, and those functions are not called within the compilation unit. Can 067a3057c3aab0cdd9a3cdb13c2e0000f69a4170 either be reverted, or a guard added so that ossl_unused is only set in the absence of a macro being defined (happy to send a PR for this). As it is currently, calling ERR_GET_LIB, ERR_GET_FUNC, ERR_GET_RFLAGS, ERR_GET_REASON, ERR_FATAL_ERROR will produce spurious "used-but-marked-unused" warnings at build time. -Arran -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From openssl-users at dukhovni.org Sat Oct 2 16:38:54 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 2 Oct 2021 12:38:54 -0400 Subject: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate ) In-Reply-To: References: Message-ID: On Sat, Oct 02, 2021 at 05:24:26PM +0200, Alex Robuchon wrote: > The project has a callback function registered with SSL_CTX_set_verify > and failed to verify DST Root CA X3 since it expired. That happens when either: * The configured trust store (perhaps not the default system trust store) does not contain the ISRG root CA certificate * The version of OpenSSL used (perhaps indirectly via some library that is linked with an older OpenSSL) is 1.0.x rather than 1.1.0 or later. > From what I understood about the let's encrypt certificate chain, R3 is > cross signed and two chained could be built: > > - leaf <- R3 <- ISRG Root X1 <- DST Root CA X3 (self-signed) > - leaf <- R3 <- ISRG Root X1 (self-signed) Yes. To make things even more complex, a few sites also have an older version of R3 that is directly signed by the DST root: - leaf <- R3 <- DST Root CA X3 (self-signed) but that's far from common at this point. > The servers by default return the first chain but from what I > understand depending on the openssl version/flags it should use the > second path if ISRG Root X1 is in the store Yes, see above. > My config : > openssl version : OpenSSL 1.1.1f 31 Mar 2020 Are you sure there are no other versions of OpenSSL also installed on the system, and/or no other trust stores that the application in question might be using instead of the default system store? An "strace" of the process should show which shared objects it is loading, and which cert store files it is opening... Best to not post the complete strace output here, it may contain sensitive data. Try to interpret it on your end and post your findings. > ISRG Root X1 self signed is in my cert store. This presumes a *singular* "trust store", but the application could easily be looking elsewhere. > So from what I understand, trusted first is default in this version of > openssl and the second path should be taken. Yes, per the pre-requisite conditions. > For the record s_client can valide the second path on my machine : > $ echo | openssl s_client -connect retouche-pro.ch:443 -name retouche-pro.ch -servername retouche-pro.ch > CONNECTED(00000003) > depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 > verify return:1 > depth=1 C = US, O = Let's Encrypt, CN = R3 > verify return:1 > depth=0 CN = retouche-pro.ch > verify return:1 As expected for 1.1.1f and a trust store that contains the ISRG X1 root. > So I suppose the problem relies on the use of openssl in the ruby > libs. Are the ruby libraries linked with OpenSSL 1.1.1? Are they overriding the default system trust store? > However what I'm a bit surprised with is the fact that > SSL_CTX_set_verify is called with the "wrong" certificate chain. I think you mean the callback specified via that function is called with unexpected chain elements, not the function itself... > The documentation says it's going to be called for each certificate in > the chain but do not specify if it's the chain specified by the server > or the one built by openssl with trusted first algorithm. Except when various earlier errors take place during chain construction, those callbacks take place as part of signature verification on the already constructed chain, so the callback normally sees the "trusted" chain, not the server provided certificate "heap" (which may not be linearly ordered). > Is it normal to have the callback defined in SSL_CTX_set_verify to be > called with the wrong chain ? Or do you think something is not configured > correctly on these gems ? See above, the callbacks report the constructed chain, except when some error happens during chain construction. -- Viktor. From angus at magsys.co.uk Sat Oct 2 17:21:00 2021 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Sat, 2 Oct 2021 18:21 +0100 (BST) Subject: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate ) In-Reply-To: Message-ID: > Yes. To make things even more complex, a few sites also have an > older version of R3 that is directly signed by the DST root: > > - leaf <- R3 <- DST Root CA X3 (self-signed) > > but that's far from common at this point. That old R3 root was issued last winter and got installed in Windows Server 2018 intermediate stores then, and was still being sent out on 29th and 30th, despite expiring on 29th. Perhaps because IIS caches server certificates. I had to delete it from the Windows store and reboot the server to stop it being sent out by IIS. Angus From openssl-users at dukhovni.org Sat Oct 2 18:11:25 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 2 Oct 2021 14:11:25 -0400 Subject: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate ) In-Reply-To: References: Message-ID: On Sat, Oct 02, 2021 at 06:21:00PM +0100, Angus Robertson - Magenta Systems Ltd wrote: > > Yes. To make things even more complex, a few sites also have an > > older version of R3 that is directly signed by the DST root: > > > > - leaf <- R3 <- DST Root CA X3 (self-signed) > > > > but that's far from common at this point. > > That old R3 [CA] was issued last winter and got installed in Windows > Server 2018 intermediate stores then, and was still being sent out on > 29th and 30th, despite expiring on 29th. Not just Windows, at least one Unix system running Postfix is still vending a chain with the R3 signed by DST that expired on 2021-09-29: issuer=O = Digital Signature Trust Co., CN = DST Root CA X3 subject=C = US, O = Let's Encrypt, CN = R3 notBefore=Oct 7 19:21:40 2020 GMT notAfter=Sep 29 19:21:40 2021 GMT SHA256 Fingerprint=73:0C:1B:DC:D8:5F:57:CE:5D:C0:BB:A7:33:E5:F1:BA:5A:92:5B:2A:77:1D:64:0A:26:F7:A4:54:22:4D:AD:3B -----BEGIN CERTIFICATE----- MIIEZTCCA02gAwIBAgIQQAF1BIMUpMghjISpDBbN3zANBgkqhkiG9w0BAQsFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTIwMTAwNzE5MjE0MFoXDTIxMDkyOTE5MjE0MFow MjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxCzAJBgNVBAMT AlIzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuwIVKMz2oJTTDxLs jVWSw/iC8ZmmekKIp10mqrUrucVMsa+Oa/l1yKPXD0eUFFU1V4yeqKI5GfWCPEKp Tm71O8Mu243AsFzzWTjn7c9p8FoLG77AlCQlh/o3cbMT5xys4Zvv2+Q7RVJFlqnB U840yFLuta7tj95gcOKlVKu2bQ6XpUA0ayvTvGbrZjR8+muLj1cpmfgwF126cm/7 gcWt0oZYPRfH5wm78Sv3htzB2nFd1EbjzK0lwYi8YGd1ZrPxGPeiXOZT/zqItkel /xMY6pgJdz+dU/nPAeX1pnAXFK9jpP+Zs5Od3FOnBv5IhR2haa4ldbsTzFID9e1R oYvbFQIDAQABo4IBaDCCAWQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8E BAMCAYYwSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5p ZGVudHJ1c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTE p7Gkeyxx+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEE AYLfEwEBATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2Vu Y3J5cHQub3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0 LmNvbS9EU1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYf r52LFMLGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0B AQsFAAOCAQEA2UzgyfWEiDcx27sT4rP8i2tiEmxYt0l+PAK3qB8oYevO4C5z70kH ejWEHx2taPDY/laBL21/WKZuNTYQHHPD5b1tXgHXbnL7KqC401dk5VvCadTQsvd8 S8MXjohyc9z9/G2948kLjmE6Flh9dDYrVYA9x2O+hEPGOaEOa1eePynBgPayvUfL qjBstzLhWVQLGAkXXmNs+5ZnPBxzDJOLxhF2JIbeQAcH5H0tZrUlo5ZYyOqA7s9p O5b85o3AM/OJ+CktFBQtfvBhcJVd9wvlwPsk+uyOy2HI7mNxKKgsBTt375teA2Tw UdHkhVNcsAKX1H7GNNLOEADksd86wuoXvg== -----END CERTIFICATE----- The EE (depth 0 server) certificate is not expired, and yet somehow the server is building a chain with a fresh leaf cert, and a rather stale issuer CA. It verifies via the DANE implementation in OpenSSL, because its "2 1 1" record with a fresh RRSIG specifies the R3 CA as trusted, and its expiration date is not in scope since it was signed by an entity outside the effective trust chain. Validation would fail for the same chain with WebPKI, unless there's a new improved R3 in the trust store (not just the roots). My DANE survey scan engine checks trust-anchor cert expiration date, even when an intermediate CA, mostly because the implementation is done that way, but I can retroactively justify it because it makes sense to be more strict in tools that look for potential issues. Implementations other than OpenSSL might similarly reject such a suboptimal chain. -- Viktor. From alexandre.robuchon at gmail.com Sun Oct 3 11:54:44 2021 From: alexandre.robuchon at gmail.com (Alex Robuchon) Date: Sun, 3 Oct 2021 13:54:44 +0200 Subject: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate ) In-Reply-To: References: Message-ID: Thanks for the detailed answer. >From strace I can see that I'm using /lib/x86_64-linux-gnu/libssl.so.1.1 When I use the eventmachine lib that uses the wrong cert chain I can see with strace : openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib/ssl/certs/2e5ac55d.0", {st_mode=S_IFREG|0644, st_size=1200, ...}) = 0 openat(AT_FDCWD, "/usr/lib/ssl/certs/2e5ac55d.0", O_RDONLY) = 8 stat("/usr/lib/ssl/certs/2e5ac55d.1", 0x7ffe1a8e5d80) = -1 ENOENT (No such file or directory) When I use another lib that uses the correct cert chain I can see with strace : openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory) stat("/usr/lib/ssl/certs/8d33f237.0", 0x7fff1b4b0f90) = -1 ENOENT (No such file or directory) stat("/usr/lib/ssl/certs/4042bcee.0", {st_mode=S_IFREG|0644, st_size=1939, ...}) = 0 openat(AT_FDCWD, "/usr/lib/ssl/certs/4042bcee.0", O_RDONLY) = 8 In the second case I can see it tries to load the R3 certificate ( 8d33f237.0 ). I wonder why in the first case it does not try to find each certificate in the chain from the trust store at all. I wonder if it can be related to the fact I do not see any call to SSL_CTX_set_cert_store in the lib. On the other hand I suppose if we do not call this it would pick the "default" trust store from the system which seems to be the case here because it can find /usr/lib/ssl/certs/2e5ac55d.0 . This looks like to be an issue in the eventmachine lib itself. I need to brush up my C skills and have a deeper look at this :). Thanks On Sat, Oct 2, 2021 at 8:11 PM Viktor Dukhovni wrote: > On Sat, Oct 02, 2021 at 06:21:00PM +0100, Angus Robertson - Magenta > Systems Ltd wrote: > > > > Yes. To make things even more complex, a few sites also have an > > > older version of R3 that is directly signed by the DST root: > > > > > > - leaf <- R3 <- DST Root CA X3 (self-signed) > > > > > > but that's far from common at this point. > > > > That old R3 [CA] was issued last winter and got installed in Windows > > Server 2018 intermediate stores then, and was still being sent out on > > 29th and 30th, despite expiring on 29th. > > Not just Windows, at least one Unix system running Postfix is still > vending a chain with the R3 signed by DST that expired on 2021-09-29: > > issuer=O = Digital Signature Trust Co., CN = DST Root CA X3 > subject=C = US, O = Let's Encrypt, CN = R3 > notBefore=Oct 7 19:21:40 2020 GMT > notAfter=Sep 29 19:21:40 2021 GMT > SHA256 > Fingerprint=73:0C:1B:DC:D8:5F:57:CE:5D:C0:BB:A7:33:E5:F1:BA:5A:92:5B:2A:77:1D:64:0A:26:F7:A4:54:22:4D:AD:3B > -----BEGIN CERTIFICATE----- > MIIEZTCCA02gAwIBAgIQQAF1BIMUpMghjISpDBbN3zANBgkqhkiG9w0BAQsFADA/ > MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT > DkRTVCBSb290IENBIFgzMB4XDTIwMTAwNzE5MjE0MFoXDTIxMDkyOTE5MjE0MFow > MjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxCzAJBgNVBAMT > AlIzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuwIVKMz2oJTTDxLs > jVWSw/iC8ZmmekKIp10mqrUrucVMsa+Oa/l1yKPXD0eUFFU1V4yeqKI5GfWCPEKp > Tm71O8Mu243AsFzzWTjn7c9p8FoLG77AlCQlh/o3cbMT5xys4Zvv2+Q7RVJFlqnB > U840yFLuta7tj95gcOKlVKu2bQ6XpUA0ayvTvGbrZjR8+muLj1cpmfgwF126cm/7 > gcWt0oZYPRfH5wm78Sv3htzB2nFd1EbjzK0lwYi8YGd1ZrPxGPeiXOZT/zqItkel > /xMY6pgJdz+dU/nPAeX1pnAXFK9jpP+Zs5Od3FOnBv5IhR2haa4ldbsTzFID9e1R > oYvbFQIDAQABo4IBaDCCAWQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8E > BAMCAYYwSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5p > ZGVudHJ1c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTE > p7Gkeyxx+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEE > AYLfEwEBATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2Vu > Y3J5cHQub3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0 > LmNvbS9EU1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYf > r52LFMLGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0B > AQsFAAOCAQEA2UzgyfWEiDcx27sT4rP8i2tiEmxYt0l+PAK3qB8oYevO4C5z70kH > ejWEHx2taPDY/laBL21/WKZuNTYQHHPD5b1tXgHXbnL7KqC401dk5VvCadTQsvd8 > S8MXjohyc9z9/G2948kLjmE6Flh9dDYrVYA9x2O+hEPGOaEOa1eePynBgPayvUfL > qjBstzLhWVQLGAkXXmNs+5ZnPBxzDJOLxhF2JIbeQAcH5H0tZrUlo5ZYyOqA7s9p > O5b85o3AM/OJ+CktFBQtfvBhcJVd9wvlwPsk+uyOy2HI7mNxKKgsBTt375teA2Tw > UdHkhVNcsAKX1H7GNNLOEADksd86wuoXvg== > -----END CERTIFICATE----- > > The EE (depth 0 server) certificate is not expired, and yet somehow the > server is building a chain with a fresh leaf cert, and a rather stale > issuer CA. > > It verifies via the DANE implementation in OpenSSL, because its "2 1 1" > record with a fresh RRSIG specifies the R3 CA as trusted, and its > expiration date is not in scope since it was signed by an entity outside > the effective trust chain. > > Validation would fail for the same chain with WebPKI, unless there's a > new improved R3 in the trust store (not just the roots). > > My DANE survey scan engine checks trust-anchor cert expiration date, > even when an intermediate CA, mostly because the implementation is > done that way, but I can retroactively justify it because it makes > sense to be more strict in tools that look for potential issues. > > Implementations other than OpenSSL might similarly reject such a > suboptimal chain. > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Oct 3 15:37:12 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 3 Oct 2021 11:37:12 -0400 Subject: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate ) In-Reply-To: References: Message-ID: On Sun, Oct 03, 2021 at 01:54:44PM +0200, Alex Robuchon wrote: > Thanks for the detailed answer. > > From strace I can see that I'm using /lib/x86_64-linux-gnu/libssl.so.1.1 > > When I use the eventmachine lib that uses the wrong cert chain I can see > with strace : Run as far away from eventmachine as you can. The very first thing you see in the code is a compiled in default "private key" (for all the world to share). https://github.com/eventmachine/eventmachine/blob/5cac87805f26b5cdc29eca713871c3374131d786/ext/ssl.cpp#L30-L123 Though applications can override these, and supply actual private keys, it does not get better from there... The comments in the code show the author punting on understanding the OpenSSL API and just guessing what to do. Indeed the code creates SSL_CTX objects without specifying either the default or explicit trust stores. The real disaster is in: https://github.com/eventmachine/eventmachine/blob/5cac87805f26b5cdc29eca713871c3374131d786/ext/ssl.cpp#L675-L698 with a completely broken SSL verification callback, that completely ignores all errors from the chain construction and signature verification code, and just attempts to "verify" each certificate in *isolation*. https://github.com/eventmachine/eventmachine/blob/5cac87805f26b5cdc29eca713871c3374131d786/ext/ssl.cpp#L693-L697 This means: * No verification of chain signatures * No verification of path constraints * No verification of name constraints * No hostname checks. * ... This code was written by someone too clueless to know what they're doing and too lazy to bother to learn. DO NOT USE IT. Do whatever it takes to never rely on this code again. Even abandon Ruby if that's what it takes... -- Viktor. From alexandre.robuchon at gmail.com Sun Oct 3 16:33:09 2021 From: alexandre.robuchon at gmail.com (Alex Robuchon) Date: Sun, 3 Oct 2021 18:33:09 +0200 Subject: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate ) In-Reply-To: References: Message-ID: I just had a big laugh Reading this. I never had to dig into openssl before so I unfortunately had to try to understand your API with eventmachine as an example. Silly me. > On the other hand I suppose if we do not call this it would pick the > "default" trust store from the system which seems to be the case here > because it can find /usr/lib/ssl/certs/2e5ac55d.0 . > Actually the part responsible for this lookup is not part of the openssl library but from the ruby callback function registered through SSL_set_verify which as you said tries to verify each certificate in isolation ( with a configured store this time ) So I suppose openssl skip the part that is supposed to build the chain when no store is configured. Do whatever it takes to never rely on this code again. Even abandon Ruby > if that's what it takes... Hopefully we do not have a lot of code relying on eventmachine so we'll see if we can improve the library or move away from it. Thanks so much for your time, explanation and responsiveness. On Sun, 3 Oct 2021, 17:37 Viktor Dukhovni, wrote: > On Sun, Oct 03, 2021 at 01:54:44PM +0200, Alex Robuchon wrote: > > > Thanks for the detailed answer. > > > > From strace I can see that I'm using /lib/x86_64-linux-gnu/libssl.so.1.1 > > > > When I use the eventmachine lib that uses the wrong cert chain I can see > > with strace : > > Run as far away from eventmachine as you can. The very first thing you > see in the code is a compiled in default "private key" (for all the > world to share). > > > https://github.com/eventmachine/eventmachine/blob/5cac87805f26b5cdc29eca713871c3374131d786/ext/ssl.cpp#L30-L123 > > Though applications can override these, and supply actual private keys, > it does not get better from there... The comments in the code show the > author punting on understanding the OpenSSL API and just guessing what > to do. > > Indeed the code creates SSL_CTX objects without specifying either the > default or explicit trust stores. > > The real disaster is in: > > > https://github.com/eventmachine/eventmachine/blob/5cac87805f26b5cdc29eca713871c3374131d786/ext/ssl.cpp#L675-L698 > > with a completely broken SSL verification callback, that completely > ignores all errors from the chain construction and signature > verification code, and just attempts to "verify" each certificate in > *isolation*. > > > https://github.com/eventmachine/eventmachine/blob/5cac87805f26b5cdc29eca713871c3374131d786/ext/ssl.cpp#L693-L697 > > This means: > > * No verification of chain signatures > * No verification of path constraints > * No verification of name constraints > * No hostname checks. > * ... > > This code was written by someone too clueless to know what they're > doing and too lazy to bother to learn. DO NOT USE IT. > > Do whatever it takes to never rely on this code again. Even abandon > Ruby if that's what it takes... > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Oct 3 16:48:38 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 3 Oct 2021 12:48:38 -0400 Subject: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate ) In-Reply-To: References: Message-ID: <5E5AC9AF-15B6-42B9-AE87-1CD144E8EFA6@dukhovni.org> > On 3 Oct 2021, at 12:33 pm, Alex Robuchon wrote: > > So I suppose openssl skip the part that is supposed to build the chain when no store is configured. Not quite, a candidate chain is constructed from whatever certificates the peer (server in your case) provided, and then passed to the callback with "preverify_ok" set to false (for the top certificate), because the chain is not trusted. But the evenmachine callback ignores "preverify_ok" and goes through the motions of doing some sort of verification of each certificate. Ultimately, it will attempt to "verify" the leaf certificate, and if it can somehow do a fair job of that (by building its own chain, checking all the signatures, doing the name checks (for a name that does not appear to be passed to the verification function), then in theory the checks at depths above 0 are just silly opportunities to fail and the EE cert check would be enough. But given all the evidence before me, I'd want to delete that code and never see it again. -- Viktor. From alexandre.robuchon at gmail.com Sun Oct 3 19:33:29 2021 From: alexandre.robuchon at gmail.com (Alex Robuchon) Date: Sun, 3 Oct 2021 21:33:29 +0200 Subject: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate ) In-Reply-To: <5E5AC9AF-15B6-42B9-AE87-1CD144E8EFA6@dukhovni.org> References: <5E5AC9AF-15B6-42B9-AE87-1CD144E8EFA6@dukhovni.org> Message-ID: > > Not quite, a candidate chain is constructed from whatever certificates the > peer (server in your case) provided, and then passed to the callback with > "preverify_ok" set to false (for the top certificate), because the chain is > not trusted. > This confuses me a little bit because I thought the callback function set with *SSL_set_verify* would have the "trusted first" valid chain. Are you sure you are not speaking as if eventmachine was using the *SSL_CTX_set_cert_verify_callback* ? >From what I see from the source code ( master ) The *tls_post_process_server_certificate* function calls ssl/ssl_cert.c#ssl_verify_cert_chain if (s->ctx->app_verify_callback != NULL) i = s->ctx->app_verify_callback(ctx, s->ctx->app_verify_arg); else i = X509_verify_cert(ctx); return i Since eventmachine do not set the *app_verify_callback* so the default *X509_verify_cert* is used from crypto/x509/x509_vfy.c (L261) The function *X509_verify_cert* calls *verify_chain(ctx)* line 295 which in turns calls: - *build_chain* that will apply the trusted first algorithm and replace the certificate chain passed by the server with the valid one ( if found ). At the point the ctx has the new chain - *internal_verify *which now has the new chain and will call *verify_callback *( the callback function passed to SSL_set_verify ) for every certificate in this new chain in reverse order. During the build_chain process I notice the ctx->get_issuer ( which actually points to X509_STORE_CTX_get1_issuer which I suppose return 0 because eventmachine do not properly set the store ) But the evenmachine callback ignores "preverify_ok" and goes through the > motions of doing some sort of verification of each certificate. > yes indeed But given all the evidence before me, I'd want to delete that code and > never see it again. > I hear you :). On Sun, Oct 3, 2021 at 6:48 PM Viktor Dukhovni wrote: > > On 3 Oct 2021, at 12:33 pm, Alex Robuchon > wrote: > > > > So I suppose openssl skip the part that is supposed to build the chain > when no store is configured. > > Not quite, a candidate chain is constructed from whatever certificates > the peer (server in your case) provided, and then passed to the callback > with "preverify_ok" set to false (for the top certificate), because the > chain is not trusted. > > But the evenmachine callback ignores "preverify_ok" and goes through the > motions of doing some sort of verification of each certificate. > > Ultimately, it will attempt to "verify" the leaf certificate, and if it > can somehow do a fair job of that (by building its own chain, checking > all the signatures, doing the name checks (for a name that does not > appear to be passed to the verification function), then in theory > the checks at depths above 0 are just silly opportunities to fail and > the EE cert check would be enough. > > But given all the evidence before me, I'd want to delete that code and > never see it again. > > -- > Viktor. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Oct 3 20:25:36 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 3 Oct 2021 16:25:36 -0400 Subject: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate ) In-Reply-To: References: <5E5AC9AF-15B6-42B9-AE87-1CD144E8EFA6@dukhovni.org> Message-ID: On Sun, Oct 03, 2021 at 09:33:29PM +0200, Alex Robuchon wrote: > > Not quite, a candidate chain is constructed from whatever certificates the > > peer (server in your case) provided, and then passed to the callback with > > "preverify_ok" set to false (for the top certificate), because the chain is > > not trusted. > > This confuses me a little bit because I thought the callback function set > with *SSL_set_verify* would have the "trusted first" valid chain. But there is no trust store configured, so trust first is a no-op. The constructed chain consists entirely of certificates from the peer, and last certificate in the chain (the ultimate issuing CA) is still not trusted, so preverify_ok = 0. > Are you sure you are not speaking as if eventmachine was using the > *SSL_CTX_set_cert_verify_callback* ? I rewrote the OpenSSL chain construction code for OpenSSL 1.1.0. Yes, I am sure. > - *build_chain* that will apply the trusted first algorithm and replace the > certificate chain passed by the server with the valid one ( if found ). The code in eventmachine does not configure any trusted certificates for the SSL_CTX handles used to create the SSL connections. So trusted-first is a no-op. > - *internal_verify *which now has the new chain and will call *verify_callback > *( the callback function passed to SSL_set_verify ) for every certificate > in this new chain in reverse order. You don't have to explain the code to me. :-) > > But given all the evidence before me, I'd want to delete that code and > > never see it again. > > I hear you :). That code is beyond repair, it needs to be thrown out, and replaced with ground up by the book TLS connection establishment. #1. No compiled in private keys #2. Configure the SSL_CTX with the desired list of trust anchors #3. Reuse the SSL_CTX for multiple connections that share the same trust and other general settings #4. Prior to SSL_connect(), tell the SSL library what hostname you want to verify via SSL_set1_host(3). Let OpenSSL do all the heavy lifting of certificate and name checks. #5. DO NOT attempt to override certificate chain verifiction in the verify callback. Use the verify callback only for logging or similar diagnostic purposes. #6. Return "preverify_ok" unmodified, unless your application is doing opportunistic unauthenticated TLS, or wants to complete the handshake even on verification failure, and then gracefully tear down the application-layer session with the peer (after checking the verification status at connection completion). If preverify_ok is false (0), OpenSSL chain verification failed, your application is unlikely to do better. Return 0, and the TLS handshake will be aborted, you can log the error reason, chain depth, ... in the verify callback. -- Viktor. From alexandre.robuchon at gmail.com Sun Oct 3 20:40:18 2021 From: alexandre.robuchon at gmail.com (Alex Robuchon) Date: Sun, 3 Oct 2021 22:40:18 +0200 Subject: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate ) In-Reply-To: References: <5E5AC9AF-15B6-42B9-AE87-1CD144E8EFA6@dukhovni.org> Message-ID: > You don't have to explain the code to me. :-) ^^. Ok. I was also trying to explain what I understood so you can correct me if I'm wrong. Everything is Cristal clear now. Thanks a million. On Sun, 3 Oct 2021, 22:25 Viktor Dukhovni, wrote: > On Sun, Oct 03, 2021 at 09:33:29PM +0200, Alex Robuchon wrote: > > > > Not quite, a candidate chain is constructed from whatever certificates > the > > > peer (server in your case) provided, and then passed to the callback > with > > > "preverify_ok" set to false (for the top certificate), because the > chain is > > > not trusted. > > > > This confuses me a little bit because I thought the callback function set > > with *SSL_set_verify* would have the "trusted first" valid chain. > > But there is no trust store configured, so trust first is a no-op. > The constructed chain consists entirely of certificates from the > peer, and last certificate in the chain (the ultimate issuing CA) > is still not trusted, so preverify_ok = 0. > > > > Are you sure you are not speaking as if eventmachine was using the > > *SSL_CTX_set_cert_verify_callback* ? > > I rewrote the OpenSSL chain construction code for OpenSSL 1.1.0. Yes, I > am sure. > > > - *build_chain* that will apply the trusted first algorithm and replace > the > > certificate chain passed by the server with the valid one ( if found ). > > The code in eventmachine does not configure any trusted certificates for > the SSL_CTX handles used to create the SSL connections. So > trusted-first is a no-op. > > > - *internal_verify *which now has the new chain and will call > *verify_callback > > *( the callback function passed to SSL_set_verify ) for every certificate > > in this new chain in reverse order. > > You don't have to explain the code to me. :-) > > > > But given all the evidence before me, I'd want to delete that code and > > > never see it again. > > > > I hear you :). > > That code is beyond repair, it needs to be thrown out, and replaced with > ground up by the book TLS connection establishment. > > #1. No compiled in private keys > > #2. Configure the SSL_CTX with the desired list of trust anchors > > #3. Reuse the SSL_CTX for multiple connections that share the same > trust and other general settings > > #4. Prior to SSL_connect(), tell the SSL library what hostname you want > to verify via SSL_set1_host(3). Let OpenSSL do all the heavy > lifting of certificate and name checks. > > #5. DO NOT attempt to override certificate chain verifiction in the > verify callback. Use the verify callback only for logging or > similar diagnostic purposes. > > #6. Return "preverify_ok" unmodified, unless your application is doing > opportunistic unauthenticated TLS, or wants to complete the > handshake even on verification failure, and then gracefully tear > down the application-layer session with the peer (after checking the > verification status at connection completion). > > If preverify_ok is false (0), OpenSSL chain verification failed, > your application is unlikely to do better. Return 0, and the > TLS handshake will be aborted, you can log the error reason, > chain depth, ... in the verify callback. > > -- > Viktor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at sectigo.com Sun Oct 3 23:09:21 2021 From: rob at sectigo.com (Rob Stradling) Date: Sun, 3 Oct 2021 23:09:21 +0000 Subject: "DST Root CA X3" expiry workaround for OpenSSL 1.0.1, 1.0.0 and 0.9.8 client applications Message-ID: The "Old Let?s Encrypt Root Certificate Expiration and OpenSSL 1.0.2" blog article [1] doesn't cover OpenSSL versions prior to 1.0.2, presumably because they've been unsupported for a long time. However, no doubt there are still some users and applications that are stuck using even older versions of OpenSSL. Here are some solutions... Firstly, it's worth noting that Workaround 1 (see [1]) also works with OpenSSL 1.0.1n and above, which seems to be because the 1.0.2 "alternative chains" behaviour was backported (see [2]). Secondly, I've come up with a variant of Workaround 1 (see "Workaround 0" below) that also works for even older OpenSSL releases. I thought I'd share it here in case it helps anyone out... ----------------------------------------------------------------------- Workaround 0 (on clients with OpenSSL >=0.9.8m) Modify the "notAfter" date in the expired root certificate (DST Root CA X3) from "Sep 30 14:01:15 2021 GMT" to "Sep 30 18:14:03 2024 GMT" (which is when the new DST->ISRG cross-certificate is due to expire - see [3] and [4]); then, in the OpenSSL-based client application's trust store, replace the expired root certificate with the modified version. Here's one way to create the modified certificate: wget -O DSTRootCAX3_Extended.crt "https://crt.sh/?d=8395" sed -i "s/xMDkzMDE0MDExNVow/0MDkzMDE4MTQwM1ow/g" DSTRootCAX3_Extended.crt You should find that "openssl s_client" with "-CAfile DSTRootCAX3_Extended.crt" will return "Verify return code: 0 (ok)" when connecting to any server that serves Let's Encrypt's preferred certificate chain (i.e., the chain that includes [4]). For example: openssl s_client -connect letsencrypt.org:443 -CAfile ../DSTRootCAX3_Extended.crt Why does this work? Modifying the expired root certificate obviously invalidates its self-signed signature. However, OpenSSL 0.9.8m and above don't check self-signed signatures by default (due to [5]), which is one factor in why this workaround works (whereas 0.9.8l and below do check self-signed signatures). The other factor is that OpenSSL treats the modified certificate as a root certificate, because the Issuer and Subject Names are identical; since it's not treated as an intermediate certificate, older versions of OpenSSL are able to treat it as a trust anchor even though they lack the "partial chains" functionality that was added in 1.0.2 (see [6]). It is not necessary to add the new ISRG Root X1 self-signed certificate to the client's trust store for Workaround 0 to work. Note however that Workaround 0 won't work beyond Sep 30 18:14:03 2024 GMT. [1] https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ [2] https://github.com/openssl/openssl/commit/f7bf8e02dfcb2c02bc12a59276d0a3ba43e6c204 [3] https://letsencrypt.org/2020/12/21/extending-android-compatibility.html [4] https://crt.sh/?id=3958242236 [5] https://github.com/openssl/openssl/commit/1e53b797f65ef6d3c2eb1052797683fec27a9ff5 [6] https://github.com/openssl/openssl/commit/9a1f59cd3128ddac73d3e0721ecd55935f53ba8b -- Rob Stradling Senior Research & Development Scientist Sectigo Limited -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe at felipegasper.com Sun Oct 3 23:14:35 2021 From: felipe at felipegasper.com (Felipe Gasper) Date: Sun, 3 Oct 2021 19:14:35 -0400 Subject: "DST Root CA X3" expiry workaround for OpenSSL 1.0.1, 1.0.0 and 0.9.8 client applications In-Reply-To: References: Message-ID: > On Oct 3, 2021, at 7:09 PM, Rob Stradling wrote: > > The "Old Let?s Encrypt Root Certificate Expiration and OpenSSL 1.0.2" blog article [1] doesn't cover OpenSSL versions prior to 1.0.2, presumably because they've been unsupported for a long time. However, no doubt there are still some users and applications that are stuck using even older versions of OpenSSL. Indeed, CentOS/RHEL 7 and earlier still use OpenSSL 1.0.2. These are widely used in shared hosting. We ended up implementing Workaround #2 in order to bring OpenSSL 1.0.x into parity with the behaviour of 1.1.0+. It would be nice--would have been helpful for me, at least--to have fleshed-out code examples. Thank you to everyone who maintains OpenSSL and who?s helping us all through this transition. cheers, -Felipe Gasper From matt at openssl.org Mon Oct 4 07:00:59 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 4 Oct 2021 08:00:59 +0100 Subject: Use of ossl_unused in err.h.in In-Reply-To: <6FDEA5D3-4869-4AF1-8EA0-D714D0EAB205@freeradius.org> References: <6FDEA5D3-4869-4AF1-8EA0-D714D0EAB205@freeradius.org> Message-ID: <75a3ee45-a533-56ac-9de7-e1aff3f86e09@openssl.org> Please raise a github issue for this. Matt On 02/10/2021 17:19, Arran Cudbard-Bell wrote: > In current master HEAD and 3.0.0 calling ERR_GET_REASON throws the following > warning: > > src/lib/tls/session.c:1323:43: warning: 'ERR_GET_REASON' was marked unused but was used [-Wused-but-marked-unused] > while ((ssl_err = ERR_peek_error()) && (ERR_GET_REASON(ssl_err) == BIO_R_UNSUPPORTED_METHOD)) { > > This is because the static inline functions in include/openssl/err.h.in have > been marked up with ossl_unused i.e. (__attribute__((unused))). > > I'm not sure what compiler the OP of https://github.com/openssl/openssl/issues/12792 > was using, but it should not be generating a -Wunused-function for a static inline > function in a header file. These are by their nature public functions, and should not > generate unused function warnings. The only correct place to generate this warnings > is when the functions's visibility is limited to the compilation unit, and those functions > are not called within the compilation unit. > > Can 067a3057c3aab0cdd9a3cdb13c2e0000f69a4170 either be reverted, or a guard > added so that ossl_unused is only set in the absence of a macro being defined (happy > to send a PR for this). > > As it is currently, calling ERR_GET_LIB, ERR_GET_FUNC, ERR_GET_RFLAGS, > ERR_GET_REASON, ERR_FATAL_ERROR will produce spurious > "used-but-marked-unused" warnings at build time. > > -Arran > From santantonioswap at gmail.com Mon Oct 4 11:12:29 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Mon, 4 Oct 2021 12:12:29 +0100 Subject: Store Mgmt and keys loading ( keyform ENG ) Message-ID: Hello, I am doing my own provider starting from the default provider's code. I have now a question, I am seeing the STOREMGMT operation is required to interpret the URI of input private key, I would like that the string passed by the user for input key is not interpret as file to open but just my provider should save the string value to be used later .This is when invoking command options such as dgst sign -in "text" -keyform ENG. With engines' architecture this is possible by passing option -keyform ENG to dgst command. The string in that case is not interpreted as a file path and just passed through. There was engine_set_load_privkey_function that was getting this string. How can I achieve this now with the provider architecture ? If I pass -keyform ENG to dgst command together with --provider , it says "no engine specified to load private key" Should I use OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I don't have a real private key info to load and use from a Filesystem. Is there anything to set in the KEYMGMT too ? I can see there is a flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key data in a key object should be considered. Not really sure if this is something I should set or not and how this keymgmt operation relates with storemgmt operation. thank you if you can send some comment on this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Mon Oct 4 11:56:09 2021 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 4 Oct 2021 13:56:09 +0200 Subject: Why custom RSA engine is not calling default RSA method? In-Reply-To: References: Message-ID: Dear Shariful, Could you please try the patch from https://github.com/openssl/openssl/pull/16734? On Wed, Sep 29, 2021 at 6:59 PM Dmitry Belyavsky wrote: > Dear Shariful, > > Yes. You have to provide all the RSA_METHO functions your app is going to > use. > > On Tue, Sep 28, 2021 at 5:46 PM Shariful Alam wrote: > >> Dear Dmitry, >> Thank you for your response. >> >> Here is the stack trace >> >> >> I was trying using gdb to debug the error. I get to until >> RSA_public_encrypt(), then if I step in, I get the segmentation fault, >> >> ================================================================================================== >> bt >> #0 0x0000000000000000 in ?? () >> #1 0x00007ffff77dbfc0 in RSA_public_encrypt (flen=72, from=0x6d8860 "Hi. >> This is a test message. Hope to see some performace gain with this.\nme", >> to=0x6d8a70 "x\353;\367\377\177", rsa=0x6d8540, padding=1) at >> crypto/rsa/rsa_crpt.c:30 >> #2 0x00000000004479a7 in rsautl_main (argc=0, argv=0x7fffffffde10) at >> apps/rsautl.c:248 >> #3 0x00000000004379fa in do_cmd (prog=0x6d5930, argc=11, >> argv=0x7fffffffde10) at apps/openssl.c:564 >> #4 0x0000000000436e4d in main (argc=11, argv=0x7fffffffde10) at >> apps/openssl.c:183 >> >> ================================================================================================== >> >> To my understanding, instead of pointing to the default encryption >> function, it is pointing to 0x0000000000000000, thus causing the >> segmentation fault. >> > > > >> >> Thanks, >> Shariful >> >> >> >> On Tue, Sep 28, 2021 at 1:40 AM Dmitry Belyavsky >> wrote: >> >>> Dear Shariful, >>> >>> Could you please also provide a stack trace of your segfault? >>> >>> On Tue, Sep 28, 2021 at 1:06 AM Shariful Alam >>> wrote: >>> >>>> Hello, >>>> I have the following simple RSA engine code from *e_dasync.c. * Following >>>> code compiles and works. Until now, I was under the impression that if I do >>>> not supply an alternative method in function *bind_dasync(), the *engine >>>> will use the default method. However, it doesn't seem to be the case. If I >>>> comment out line 37 and try to perform an encryption operation with the >>>> following command, >>>> >>>> *"openssl rsautl -encrypt -inkey public.pem -pubin -in msg.txt -out >>>> msg.enc -engine rsa-engine-new" * >>>> >>>> I get segmentation errors. >>>> >>>> Can anyone please tell me why this is happening? >>>> >>>> >>>> ============================================================================== >>>> >>>> 1. /* Engine Id and Name */ >>>> 2. static const char *engine_rsa_id = "rsa-engine-new"; >>>> 3. static const char *engine_rsa_name = "RSA engine for testing"; >>>> 4. >>>> 5. // data encryption function >>>> 6. static int eng_rsa_pub_enc(int flen, const unsigned char *from, >>>> 7. unsigned char *to, RSA *rsa, int >>>> padding) { >>>> 8. printf("Encryption\n"); >>>> 9. return 0; >>>> 10. } >>>> 11. >>>> 12. // signature verify >>>> 13. static int eng_rsa_pub_dec(int flen, const unsigned char *from, >>>> unsigned char *to, RSA *rsa, int padding){ >>>> 14. printf("Signature verify:\n"); >>>> 15. return 0; >>>> 16. } >>>> 17. >>>> 18. // signature >>>> 19. static int eng_rsa_priv_enc(int flen, const unsigned char >>>> *from, unsigned char *to, RSA *rsa, int padding){ >>>> 20. printf("Signature:\n"); >>>> 21. return 0; >>>> 22. } >>>> 23. >>>> 24. // data decryption >>>> 25. static int eng_rsa_priv_dec(int flen, const unsigned char >>>> *from, unsigned char *to, RSA *rsa, int padding){ >>>> 26. printf("Decryption\n"); >>>> 27. return 0; >>>> 28. } >>>> 29. >>>> 30. >>>> 31. static RSA_METHOD *test_rsa_method = NULL; >>>> 32. >>>> 33. >>>> 34. static int bind_dasync(ENGINE *e){ >>>> 35. /* Setup RSA_METHOD */ >>>> 36. if ((test_rsa_method = RSA_meth_new("Test RSA method", 0)) >>>> == NULL >>>> 37. // || RSA_meth_set_pub_enc(test_rsa_method, >>>> eng_rsa_pub_enc) == 0 >>>> 38. || RSA_meth_set_pub_dec(test_rsa_method, >>>> eng_rsa_pub_dec) == 0 >>>> 39. || RSA_meth_set_priv_enc(test_rsa_method, >>>> eng_rsa_priv_enc) == 0 >>>> 40. || RSA_meth_set_priv_dec(test_rsa_method, >>>> eng_rsa_priv_dec) == 0 >>>> 41. ) { >>>> 42. >>>> 43. return 0; >>>> 44. } >>>> 45. >>>> 46. /* Ensure the dasync error handling is set up */ >>>> 47. >>>> 48. if (!ENGINE_set_id(e, engine_rsa_id) >>>> 49. || !ENGINE_set_name(e, engine_rsa_name) >>>> 50. || !ENGINE_set_RSA(e, test_rsa_method) >>>> 51. ) { >>>> 52. return 0; >>>> 53. } >>>> 54. return 1; >>>> 55. } >>>> 56. >>>> 57. static int bind_helper(ENGINE *e, const char *id){ >>>> 58. if (!bind_dasync(e)){ >>>> 59. printf("2_Error: Inside Bind helper\n"); >>>> 60. return 0; >>>> 61. } >>>> 62. return 1; >>>> 63. } >>>> 64. >>>> 65. IMPLEMENT_DYNAMIC_BIND_FN(bind_helper) >>>> 66. IMPLEMENT_DYNAMIC_CHECK_FN() >>>> >>>> >>>> ============================================================================== >>>> >>>> Regards, >>>> Shariful Alam >>>> >>>> >>> >>> -- >>> SY, Dmitry Belyavsky >>> >> > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From santantonioswap at gmail.com Mon Oct 4 12:38:09 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Mon, 4 Oct 2021 13:38:09 +0100 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: Message-ID: Forgot to write, I am using Openssl 3.0. Thank you On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, wrote: > Hello, > I am doing my own provider starting from the default provider's code. > I have now a question, I am seeing the STOREMGMT operation is required to > interpret the URI of input private key, I would like that the string > passed by the user for input key is not interpret as file to open but just > my provider should save the string value to be used later .This is when > invoking command options such as dgst sign -in "text" -keyform ENG. > With engines' architecture this is possible by passing option -keyform ENG > to dgst command. The string in that case is not interpreted as a file path > and just passed through. > There was engine_set_load_privkey_function that was getting this string. > How can I achieve this now with the provider architecture ? If I pass > -keyform ENG to dgst command together with --provider , it says "no engine > specified to load private key" Should I use OSSL_FUNC_store_load_fn and > OSSL_FUNC_store_open_fn ? . > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I don't have a > real private key info to load and use from a Filesystem. > Is there anything to set in the KEYMGMT too ? I can see there is a flag > OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key data in a key > object should be considered. Not really sure if this is something I should > set or not and how this keymgmt operation relates with storemgmt operation. > > thank you if you can send some comment on this. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From santantonioswap at gmail.com Mon Oct 4 12:56:50 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Mon, 4 Oct 2021 13:56:50 +0100 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: Message-ID: I checked the sources, I found that keyform cannot be set to ENGINE if engine is not specified in the command options, this is in the function make_engine_url() called from load_key() when format==FORMAT_ENGINE. I am not specifying engine in the dgst command options as I am using a provider. I would like to achieve the same as FORMAT_ENGINE does, but with provider. On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, wrote: > Hello, > I am doing my own provider starting from the default provider's code. > I have now a question, I am seeing the STOREMGMT operation is required to > interpret the URI of input private key, I would like that the string > passed by the user for input key is not interpret as file to open but just > my provider should save the string value to be used later .This is when > invoking command options such as dgst sign -in "text" -keyform ENG. > With engines' architecture this is possible by passing option -keyform ENG > to dgst command. The string in that case is not interpreted as a file path > and just passed through. > There was engine_set_load_privkey_function that was getting this string. > How can I achieve this now with the provider architecture ? If I pass > -keyform ENG to dgst command together with --provider , it says "no engine > specified to load private key" Should I use OSSL_FUNC_store_load_fn and > OSSL_FUNC_store_open_fn ? . > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I don't have a > real private key info to load and use from a Filesystem. > Is there anything to set in the KEYMGMT too ? I can see there is a flag > OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key data in a key > object should be considered. Not really sure if this is something I should > set or not and how this keymgmt operation relates with storemgmt operation. > > thank you if you can send some comment on this. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Mon Oct 4 13:13:14 2021 From: tomas at openssl.org (Tomas Mraz) Date: Mon, 04 Oct 2021 15:13:14 +0200 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: Message-ID: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> You would have to implement a STORE provider that handles your special url scheme and then the keys would be referenced by the yourscheme://any-identifier-you-have. Of course the application (i.e., the openssl application which already does this) would have to use the OSSL_STORE API to load the keys and not directly the OSSL_DECODER API or the d2i/PEM_read APIs. Tomas On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: > I checked the sources, I found that keyform cannot be set to ENGINE > if engine is not specified in the command options, this is in the > function make_engine_url() called from load_key() when > format==FORMAT_ENGINE.? > I am not specifying engine in the dgst command options as I am using > a? provider. > I would like to achieve the same as FORMAT_ENGINE does, but with > provider. > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, > wrote: > > Hello,? > > I am doing my own provider starting from the default provider's > > code. > > I have now a question, I am seeing the STOREMGMT operation is > > required to interpret the URI of input private key,? I would like > > that the string passed by the user for input key is not interpret > > as file to open but just my provider should save the string value > > to be used later .This is? when invoking command options such as > > dgst sign -in "text" -keyform ENG. > > With engines' architecture this is possible by passing option - > > keyform ENG to dgst command. The string in that case is not > > interpreted as a file path and just passed through. > > There was engine_set_load_privkey_function that was getting this > > string. > > How can I achieve this now with the provider architecture ? If I > > pass -keyform ENG to dgst command together with --provider , it > > says "no engine specified to load private key" Should I use > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I don't > > have a real private key info to load and use from a Filesystem. > > Is there anything to set in the KEYMGMT too ? I can see there is a > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key > > data in a key object should be considered. Not really sure if this > > is something I should set or not and how this keymgmt operation > > relates with storemgmt operation.? > > > > thank you if you can send some comment on this. > > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From santantonioswap at gmail.com Mon Oct 4 14:39:18 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Mon, 4 Oct 2021 15:39:18 +0100 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> References: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> Message-ID: Thank you for your comment. Am I wrong then in saying that dgst and possibly other apps are not ready to be used with providers rather than engines in the case you need keyform=ENGINE ? On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: > You would have to implement a STORE provider that handles your special > url scheme and then the keys would be referenced by the > yourscheme://any-identifier-you-have. Of course the application (i.e., > the openssl application which already does this) would have to use the > OSSL_STORE API to load the keys and not directly the OSSL_DECODER API > or the d2i/PEM_read APIs. > > Tomas > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: > > I checked the sources, I found that keyform cannot be set to ENGINE > > if engine is not specified in the command options, this is in the > > function make_engine_url() called from load_key() when > > format==FORMAT_ENGINE. > > I am not specifying engine in the dgst command options as I am using > > a provider. > > I would like to achieve the same as FORMAT_ENGINE does, but with > > provider. > > > > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, > > wrote: > > > Hello, > > > I am doing my own provider starting from the default provider's > > > code. > > > I have now a question, I am seeing the STOREMGMT operation is > > > required to interpret the URI of input private key, I would like > > > that the string passed by the user for input key is not interpret > > > as file to open but just my provider should save the string value > > > to be used later .This is when invoking command options such as > > > dgst sign -in "text" -keyform ENG. > > > With engines' architecture this is possible by passing option - > > > keyform ENG to dgst command. The string in that case is not > > > interpreted as a file path and just passed through. > > > There was engine_set_load_privkey_function that was getting this > > > string. > > > How can I achieve this now with the provider architecture ? If I > > > pass -keyform ENG to dgst command together with --provider , it > > > says "no engine specified to load private key" Should I use > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I don't > > > have a real private key info to load and use from a Filesystem. > > > Is there anything to set in the KEYMGMT too ? I can see there is a > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key > > > data in a key object should be considered. Not really sure if this > > > is something I should set or not and how this keymgmt operation > > > relates with storemgmt operation. > > > > > > thank you if you can send some comment on this. > > > > > -- > Tom?? Mr?z > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Mon Oct 4 14:45:35 2021 From: tomas at openssl.org (Tomas Mraz) Date: Mon, 04 Oct 2021 16:45:35 +0200 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> Message-ID: <033cf963496decbca923af5d8ba4b1781ac1fd65.camel@openssl.org> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already modified to use OSSL_STORE API to load keys. So you do not need to specify keyform=ENGINE if your key is provided by a provider that supports the STORE functionality for some special URL scheme. You just specify the right URL with that scheme to reference the key in the provider. Of course third party applications need to be modified to call OSSL_STORE API in a similar way how the openssl application does it. Tomas On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: > Thank you for your comment. > Am I wrong then in saying that dgst and possibly other apps are not > ready to be used with providers? rather than engines in the case you > need keyform=ENGINE ? > > > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: > > You would have to implement a STORE provider that handles your > > special > > url scheme and then the keys would be referenced by the > > yourscheme://any-identifier-you-have. Of course the application > > (i.e., > > the openssl application which already does this) would have to use > > the > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER > > API > > or the d2i/PEM_read APIs. > > > > Tomas > > > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: > > > I checked the sources, I found that keyform cannot be set to > > > ENGINE > > > if engine is not specified in the command options, this is in the > > > function make_engine_url() called from load_key() when > > > format==FORMAT_ENGINE.? > > > I am not specifying engine in the dgst command options as I am > > using > > > a? provider. > > > I would like to achieve the same as FORMAT_ENGINE does, but with > > > provider. > > > > > > > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, > > > wrote: > > > > Hello,? > > > > I am doing my own provider starting from the default provider's > > > > code. > > > > I have now a question, I am seeing the STOREMGMT operation is > > > > required to interpret the URI of input private key,? I would > > > > like > > > > that the string passed by the user for input key is not > > > > interpret > > > > as file to open but just my provider should save the string > > > > value > > > > to be used later .This is? when invoking command options such > > > > as > > > > dgst sign -in "text" -keyform ENG. > > > > With engines' architecture this is possible by passing option - > > > > keyform ENG to dgst command. The string in that case is not > > > > interpreted as a file path and just passed through. > > > > There was engine_set_load_privkey_function that was getting > > > > this > > > > string. > > > > How can I achieve this now with the provider architecture ? If > > > > I > > > > pass -keyform ENG to dgst command together with --provider , it > > > > says "no engine specified to load private key" Should I use > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I > > don't > > > > have a real private key info to load and use from a Filesystem. > > > > Is there anything to set in the KEYMGMT too ? I can see there > > > > is > > a > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key > > > > data in a key object should be considered. Not really sure if > > this > > > > is something I should set or not and how this keymgmt operation > > > > relates with storemgmt operation.? > > > > > > > > thank you if you can send some comment on this. > > > > > > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From santantonioswap at gmail.com Mon Oct 4 15:52:45 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Mon, 4 Oct 2021 16:52:45 +0100 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: <033cf963496decbca923af5d8ba4b1781ac1fd65.camel@openssl.org> References: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> <033cf963496decbca923af5d8ba4b1781ac1fd65.camel@openssl.org> Message-ID: OK, thank you very much for your comments, that's clear. On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote: > No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already > modified to use OSSL_STORE API to load keys. So you do not need to > specify keyform=ENGINE if your key is provided by a provider that > supports the STORE functionality for some special URL scheme. You just > specify the right URL with that scheme to reference the key in the > provider. > > Of course third party applications need to be modified to call > OSSL_STORE API in a similar way how the openssl application does it. > > Tomas > > On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: > > Thank you for your comment. > > Am I wrong then in saying that dgst and possibly other apps are not > > ready to be used with providers rather than engines in the case you > > need keyform=ENGINE ? > > > > > > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: > > > You would have to implement a STORE provider that handles your > > > special > > > url scheme and then the keys would be referenced by the > > > yourscheme://any-identifier-you-have. Of course the application > > > (i.e., > > > the openssl application which already does this) would have to use > > > the > > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER > > > API > > > or the d2i/PEM_read APIs. > > > > > > Tomas > > > > > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: > > > > I checked the sources, I found that keyform cannot be set to > > > > ENGINE > > > > if engine is not specified in the command options, this is in the > > > > function make_engine_url() called from load_key() when > > > > format==FORMAT_ENGINE. > > > > I am not specifying engine in the dgst command options as I am > > > using > > > > a provider. > > > > I would like to achieve the same as FORMAT_ENGINE does, but with > > > > provider. > > > > > > > > > > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, > > > > wrote: > > > > > Hello, > > > > > I am doing my own provider starting from the default provider's > > > > > code. > > > > > I have now a question, I am seeing the STOREMGMT operation is > > > > > required to interpret the URI of input private key, I would > > > > > like > > > > > that the string passed by the user for input key is not > > > > > interpret > > > > > as file to open but just my provider should save the string > > > > > value > > > > > to be used later .This is when invoking command options such > > > > > as > > > > > dgst sign -in "text" -keyform ENG. > > > > > With engines' architecture this is possible by passing option - > > > > > keyform ENG to dgst command. The string in that case is not > > > > > interpreted as a file path and just passed through. > > > > > There was engine_set_load_privkey_function that was getting > > > > > this > > > > > string. > > > > > How can I achieve this now with the provider architecture ? If > > > > > I > > > > > pass -keyform ENG to dgst command together with --provider , it > > > > > says "no engine specified to load private key" Should I use > > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . > > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I > > > don't > > > > > have a real private key info to load and use from a Filesystem. > > > > > Is there anything to set in the KEYMGMT too ? I can see there > > > > > is > > > a > > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key > > > > > data in a key object should be considered. Not really sure if > > > this > > > > > is something I should set or not and how this keymgmt operation > > > > > relates with storemgmt operation. > > > > > > > > > > thank you if you can send some comment on this. > > > > > > > > > > -- > Tom?? Mr?z > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Mon Oct 4 18:36:48 2021 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 04 Oct 2021 14:36:48 -0400 Subject: "DST Root CA X3" expiry workaround for OpenSSL 1.0.1, 1.0.0 and 0.9.8 client applications In-Reply-To: References: Message-ID: <19360.1633372608@localhost> I got a call on Thursday from my mom asking why Apple Mail couldn't SMTP deliver to my LE signed SMTP server. She forgot how to start teamviewer, so a Saturday morning trip to the small town she lives in later... and it she looks like a problem with anchors. On a brand new MacOS system from this year. (Her old iMac had long sinced reached it's maximum OS level and was sadly, replaced) The machine did want to apply updates, which allowed, but I don't know if those updates solved the problem because I had already overridden things. I was surprised anyway, and I'm just posting this as a datapoint. I don't have many details. I don't know what libraries Apple Mail uses. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From artem.goussev at gmail.com Mon Oct 4 19:42:25 2021 From: artem.goussev at gmail.com (Artem Goussev) Date: Mon, 4 Oct 2021 22:42:25 +0300 Subject: fips 140-2 module conditions and compilation target app Message-ID: hi, I develop my application and I need to use OpenSSL 1.0.2 with the OpenSSL FIPS Object Module 2.0. I know that OpenSSL 3.0 was released, but unfortunately I must use OpenSSL 1.0.2. I have read OpenSSL FIPS Object Module 2.0 documentation and I have one misunderstanding. *"note that as a condition of the FIPS 140-2 validation no other user specified configuration options may be specified."* Does it mean that I can't make any changes in the build configuration files? For example, can I change some compilation flags(CFLAGS) or change the list of linked libraries in makefile or others? If I do it will I lose some FIPS-140-2 validation or as a result, will I get an incorrect FIPS 140-2 library or will I lose some FIPS 140-2 compliance ? Can you explain it to me please ? i already know that i can't change any configuration settings in make files. it means that command ms\do_fips build fips module with CFLAG /MD and I can't change it, corect? i can't build a fips module with option /MT, correct? So it means I can use openssl only in /MD mode, correct? so my target windows console app\dll can be only in /MD mode, correct? can you help me to understand plz? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Mon Oct 4 23:42:10 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 5 Oct 2021 09:42:10 +1000 Subject: fips 140-2 module conditions and compilation target app In-Reply-To: References: Message-ID: <207e7c48-c66c-97d0-b9f8-3ae84d45c755@openssl.org> I think you've got the fist of the restriction.? You cannot make any changes to the source code, build files or the commands you use to build the FOM.? None are acceptable if you want a FIPS validate outcome.? I.e. you will lose the FIPS 140-2 validation state if you change anything. Pauli On 5/10/21 5:42 am, Artem Goussev wrote: > ?hi, > I develop my application and I need to use OpenSSL?1.0.2 with the > OpenSSL FIPS Object Module 2.0. I know that OpenSSL 3.0 was > released,?but unfortunately I must use?OpenSSL 1.0.2. > > I have read? ?OpenSSL FIPS Object Module 2.0?documentation and I have > one misunderstanding. > > *"note that as a condition of the FIPS 140-2 validation no other user > specified configuration options may be specified."* > * > * > Does it mean that I can't make any changes in the build configuration > files? For example, can I change some compilation flags(CFLAGS) or > change the list of linked libraries in makefile or others? If I do it > will I lose some FIPS-140-2 validation or as a result, will I get an > incorrect FIPS 140-2 library or will I lose some FIPS 140-2 compliance > ? Can you explain it to me please ? > > i already know that i can't change any configuration settings in make > files. > > it means that command > ? ? ? ms\do_fips > build fips module with CFLAG /MD > > > and I can't change it,?corect? i can't build a fips module with option > /MT, correct? > > > So it means I can use openssl only in /MD mode, correct? so my target > windows console app\dll can be only in /MD mode, correct? > > can you help me to understand plz? > > thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shivakumar.Poojari at rbbn.com Tue Oct 5 04:24:15 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Tue, 5 Oct 2021 04:24:15 +0000 Subject: Alternative for structure opaque X509 & X509_STORE_CTX Message-ID: Hi Matt, Seen this comment in GitHub OpenSSL 1.1.0 made many structures opaque. You cannot directly access the fields inside the X509 structure any more. Instead you must use accessor functions. In this case, as @slontis says, you must use the function X509_get0_signature() https://github.com/openssl/openssl/issues/12447#issuecomment-660958868 :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} if (x->ocsp && x->ocsp->ocsp_url) :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} if(cert->sig_alg) :types.h:157:16: note: forward declaration of 'X509' {aka 'struct x509_st'} typedef struct x509_st X509; error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} sigAlg = OBJ_obj2nid((cert)->sig_alg->algorithm); error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} x = ctx->cert; ^~ types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} typedef struct x509_store_ctx_st X509_STORE_CTX; ^~~~~~~~~~~~~~~~~ error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} ctx->current_cert = x; ^~ error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} ctx->current_issuer = NULL; ^~ error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} ctx->current_crl_score = 0; ^~ types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} typedef struct x509_store_ctx_st X509_STORE_CTX; ^~~~~~~~~~~~~~~~~ types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} typedef struct x509_store_ctx_st X509_STORE_CTX; ^~~~~~~~~~~~~~~~~ /sonus/p4/ws/spoojari/openssl3/marlin/SIPCM/sipCmOpenSSL.c:3268:8: error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} ctx->current_reasons = 0; ^~ error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} ctx->error = 0; ^~ error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} if (px->ocsp && (px->ocsp->ocsp_validate == X509_OCSP_VALIDATE_DISABLED)) ^~ error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} if (!ctx->ctx->ocsp_process_responder) ^~ error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} store = ctx->ctx; ^~ error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct x509_store_ctx_st'} ok = ctx->verify_cb(0, ctx); ^~ Getting above error in the code, Please provide the document that which function i can use to resolve this errors. Thanks, Shiva kumar Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Oct 5 07:50:25 2021 From: matt at openssl.org (Matt Caswell) Date: Tue, 5 Oct 2021 08:50:25 +0100 Subject: Alternative for structure opaque X509 & X509_STORE_CTX In-Reply-To: References: Message-ID: On 05/10/2021 05:24, Shivakumar Poojari wrote: > :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > ? ? ?if (x->ocsp && x->ocsp->ocsp_url) Strangely there is no ocsp field in an x509_st even in 1.0.2 that I can see. > > :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > ? ? ? ? ?if(cert->sig_alg) > > :types.h:157:16: note: forward declaration of 'X509' {aka 'struct x509_st'} > ?typedef struct x509_st X509; > > error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > ? ? ? ? ? ? ?sigAlg = OBJ_obj2nid((cert)->sig_alg->algorithm); sig_alg is an X509_ALGOR structure which you get can using X509_get0_signature(). > > ?error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ? ? ?x = ctx->cert; X509_STORE_CTX_get_current_cert() > ? ? ? ? ? ? ^~ > types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka > 'struct x509_store_ctx_st'} > ?typedef struct x509_store_ctx_st X509_STORE_CTX; > ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ? ? ?ctx->current_cert = x; X509_STORE_CTX_set_current_cert() > ? ? ? ? ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ? ? ?ctx->current_issuer = NULL; > ? ? ? ? ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ? ? ?ctx->current_crl_score = 0; > ? ? ? ? ^~ > > types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka > 'struct x509_store_ctx_st'} > ?typedef struct x509_store_ctx_st X509_STORE_CTX; > ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~ > > types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka > 'struct x509_store_ctx_st'} > ?typedef struct x509_store_ctx_st X509_STORE_CTX; > ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~ > /sonus/p4/ws/spoojari/openssl3/marlin/SIPCM/sipCmOpenSSL.c:3268:8: > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ? ? ?ctx->current_reasons = 0; These fields can't be set individually. You have to reset the whole X509_STORE_CTX, e.g. via X509_STORE_CTX_init. > ? ? ? ? ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ? ? ?ctx->error = 0; X509_STORE_CTX_set_error() > ? ? ? ? ^~ > error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > ? ? ? ? ? ? ?if (px->ocsp && (px->ocsp->ocsp_validate == > X509_OCSP_VALIDATE_DISABLED)) > ? ? ? ? ? ? ? ? ? ?^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ? ? ? ? ?if (!ctx->ctx->ocsp_process_responder) > ? ? ? ? ? ? ? ? ?^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ? ? ?store = ctx->ctx; > Use X509_STORE_CTX_get0_store() to get ctx->ctx. I can't find the field "ocsp_process_responder" ? ? ? ? ? ? ? ? ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ? ? ? ? ?ok = ctx->verify_cb(0, ctx); X509_STORE_get_verify_cb() > ? ? ? ? ? ? ? ? ?^~ > Getting above error in the code, Please provide the document that which > function i can use to resolve this errors. > > Thanks, > Shiva kumar > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. From Shivakumar.Poojari at rbbn.com Tue Oct 5 09:04:47 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Tue, 5 Oct 2021 09:04:47 +0000 Subject: [EXTERNAL] Re: Alternative for structure opaque X509 & X509_STORE_CTX In-Reply-To: References: Message-ID: Thanks Matt!! your suggestions are very helpful. ________________________________ From: Matt Caswell Sent: Tuesday, October 5, 2021 1:20 PM To: Shivakumar Poojari ; openssl-users at openssl.org Cc: Paramashivaiah, Sunil ; Kumar Mishra, Sanjeev ; Bhattacharjee, Debapriyo (c) Subject: [EXTERNAL] Re: Alternative for structure opaque X509 & X509_STORE_CTX On 05/10/2021 05:24, Shivakumar Poojari wrote: > :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > if (x->ocsp && x->ocsp->ocsp_url) Strangely there is no ocsp field in an x509_st even in 1.0.2 that I can see. > > :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > if(cert->sig_alg) > > :types.h:157:16: note: forward declaration of 'X509' {aka 'struct x509_st'} > typedef struct x509_st X509; > > error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > sigAlg = OBJ_obj2nid((cert)->sig_alg->algorithm); sig_alg is an X509_ALGOR structure which you get can using X509_get0_signature(). > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > x = ctx->cert; X509_STORE_CTX_get_current_cert() > ^~ > types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka > 'struct x509_store_ctx_st'} > typedef struct x509_store_ctx_st X509_STORE_CTX; > ^~~~~~~~~~~~~~~~~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ctx->current_cert = x; X509_STORE_CTX_set_current_cert() > ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ctx->current_issuer = NULL; > ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ctx->current_crl_score = 0; > ^~ > > types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka > 'struct x509_store_ctx_st'} > typedef struct x509_store_ctx_st X509_STORE_CTX; > ^~~~~~~~~~~~~~~~~ > > types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka > 'struct x509_store_ctx_st'} > typedef struct x509_store_ctx_st X509_STORE_CTX; > ^~~~~~~~~~~~~~~~~ > /sonus/p4/ws/spoojari/openssl3/marlin/SIPCM/sipCmOpenSSL.c:3268:8: > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ctx->current_reasons = 0; These fields can't be set individually. You have to reset the whole X509_STORE_CTX, e.g. via X509_STORE_CTX_init. > ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ctx->error = 0; X509_STORE_CTX_set_error() > ^~ > error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > if (px->ocsp && (px->ocsp->ocsp_validate == > X509_OCSP_VALIDATE_DISABLED)) > ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > if (!ctx->ctx->ocsp_process_responder) > ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > store = ctx->ctx; > Use X509_STORE_CTX_get0_store() to get ctx->ctx. I can't find the field "ocsp_process_responder" ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ok = ctx->verify_cb(0, ctx); X509_STORE_get_verify_cb() > ^~ > Getting above error in the code, Please provide the document that which > function i can use to resolve this errors. > > Thanks, > Shiva kumar > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jqian at tibco.com Tue Oct 5 13:17:52 2021 From: jqian at tibco.com (Jason Qian) Date: Tue, 5 Oct 2021 09:17:52 -0400 Subject: Help on mixed encrypt/decrypt data using C++/java Message-ID: Hi, We encrypt data using openSSL C++ API, decrypt data using java(default security package). 99.9% of the time, it works fine, but when multi-instances of apps encrypt data at same time, java fails to decrypt . We are using version 1.1.01 (AES/CBC/PKCS5Padding) mpCtx = EVP_CIPHER_CTX_new(); EVP_CIPHER_CTX_init(mpCtx); Thanks for helping, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From dipto181 at gmail.com Tue Oct 5 21:26:05 2021 From: dipto181 at gmail.com (Shariful Alam) Date: Tue, 5 Oct 2021 15:26:05 -0600 Subject: Why custom RSA engine is not calling default RSA method? In-Reply-To: References: Message-ID: Dear Dmitry, Thanks for sharing the patch. I will try and let you know the results. Thanks, Shariful On Mon, Oct 4, 2021 at 5:56 AM Dmitry Belyavsky wrote: > Dear Shariful, > > Could you please try the patch from > https://github.com/openssl/openssl/pull/16734? > > On Wed, Sep 29, 2021 at 6:59 PM Dmitry Belyavsky > wrote: > >> Dear Shariful, >> >> Yes. You have to provide all the RSA_METHO functions your app is going to >> use. >> >> On Tue, Sep 28, 2021 at 5:46 PM Shariful Alam wrote: >> >>> Dear Dmitry, >>> Thank you for your response. >>> >>> Here is the stack trace >>> >>> >>> I was trying using gdb to debug the error. I get to until >>> RSA_public_encrypt(), then if I step in, I get the segmentation fault, >>> >>> ================================================================================================== >>> bt >>> #0 0x0000000000000000 in ?? () >>> #1 0x00007ffff77dbfc0 in RSA_public_encrypt (flen=72, from=0x6d8860 >>> "Hi. This is a test message. Hope to see some performace gain with >>> this.\nme", to=0x6d8a70 "x\353;\367\377\177", rsa=0x6d8540, padding=1) at >>> crypto/rsa/rsa_crpt.c:30 >>> #2 0x00000000004479a7 in rsautl_main (argc=0, argv=0x7fffffffde10) at >>> apps/rsautl.c:248 >>> #3 0x00000000004379fa in do_cmd (prog=0x6d5930, argc=11, >>> argv=0x7fffffffde10) at apps/openssl.c:564 >>> #4 0x0000000000436e4d in main (argc=11, argv=0x7fffffffde10) at >>> apps/openssl.c:183 >>> >>> ================================================================================================== >>> >>> To my understanding, instead of pointing to the default encryption >>> function, it is pointing to 0x0000000000000000, thus causing the >>> segmentation fault. >>> >> >> >> >>> >>> Thanks, >>> Shariful >>> >>> >>> >>> On Tue, Sep 28, 2021 at 1:40 AM Dmitry Belyavsky >>> wrote: >>> >>>> Dear Shariful, >>>> >>>> Could you please also provide a stack trace of your segfault? >>>> >>>> On Tue, Sep 28, 2021 at 1:06 AM Shariful Alam >>>> wrote: >>>> >>>>> Hello, >>>>> I have the following simple RSA engine code from *e_dasync.c. * Following >>>>> code compiles and works. Until now, I was under the impression that if I do >>>>> not supply an alternative method in function *bind_dasync(), the *engine >>>>> will use the default method. However, it doesn't seem to be the case. If I >>>>> comment out line 37 and try to perform an encryption operation with the >>>>> following command, >>>>> >>>>> *"openssl rsautl -encrypt -inkey public.pem -pubin -in msg.txt -out >>>>> msg.enc -engine rsa-engine-new" * >>>>> >>>>> I get segmentation errors. >>>>> >>>>> Can anyone please tell me why this is happening? >>>>> >>>>> >>>>> ============================================================================== >>>>> >>>>> 1. /* Engine Id and Name */ >>>>> 2. static const char *engine_rsa_id = "rsa-engine-new"; >>>>> 3. static const char *engine_rsa_name = "RSA engine for testing"; >>>>> 4. >>>>> 5. // data encryption function >>>>> 6. static int eng_rsa_pub_enc(int flen, const unsigned char *from, >>>>> 7. unsigned char *to, RSA *rsa, int >>>>> padding) { >>>>> 8. printf("Encryption\n"); >>>>> 9. return 0; >>>>> 10. } >>>>> 11. >>>>> 12. // signature verify >>>>> 13. static int eng_rsa_pub_dec(int flen, const unsigned char >>>>> *from, unsigned char *to, RSA *rsa, int padding){ >>>>> 14. printf("Signature verify:\n"); >>>>> 15. return 0; >>>>> 16. } >>>>> 17. >>>>> 18. // signature >>>>> 19. static int eng_rsa_priv_enc(int flen, const unsigned char >>>>> *from, unsigned char *to, RSA *rsa, int padding){ >>>>> 20. printf("Signature:\n"); >>>>> 21. return 0; >>>>> 22. } >>>>> 23. >>>>> 24. // data decryption >>>>> 25. static int eng_rsa_priv_dec(int flen, const unsigned char >>>>> *from, unsigned char *to, RSA *rsa, int padding){ >>>>> 26. printf("Decryption\n"); >>>>> 27. return 0; >>>>> 28. } >>>>> 29. >>>>> 30. >>>>> 31. static RSA_METHOD *test_rsa_method = NULL; >>>>> 32. >>>>> 33. >>>>> 34. static int bind_dasync(ENGINE *e){ >>>>> 35. /* Setup RSA_METHOD */ >>>>> 36. if ((test_rsa_method = RSA_meth_new("Test RSA method", 0)) >>>>> == NULL >>>>> 37. // || RSA_meth_set_pub_enc(test_rsa_method, >>>>> eng_rsa_pub_enc) == 0 >>>>> 38. || RSA_meth_set_pub_dec(test_rsa_method, >>>>> eng_rsa_pub_dec) == 0 >>>>> 39. || RSA_meth_set_priv_enc(test_rsa_method, >>>>> eng_rsa_priv_enc) == 0 >>>>> 40. || RSA_meth_set_priv_dec(test_rsa_method, >>>>> eng_rsa_priv_dec) == 0 >>>>> 41. ) { >>>>> 42. >>>>> 43. return 0; >>>>> 44. } >>>>> 45. >>>>> 46. /* Ensure the dasync error handling is set up */ >>>>> 47. >>>>> 48. if (!ENGINE_set_id(e, engine_rsa_id) >>>>> 49. || !ENGINE_set_name(e, engine_rsa_name) >>>>> 50. || !ENGINE_set_RSA(e, test_rsa_method) >>>>> 51. ) { >>>>> 52. return 0; >>>>> 53. } >>>>> 54. return 1; >>>>> 55. } >>>>> 56. >>>>> 57. static int bind_helper(ENGINE *e, const char *id){ >>>>> 58. if (!bind_dasync(e)){ >>>>> 59. printf("2_Error: Inside Bind helper\n"); >>>>> 60. return 0; >>>>> 61. } >>>>> 62. return 1; >>>>> 63. } >>>>> 64. >>>>> 65. IMPLEMENT_DYNAMIC_BIND_FN(bind_helper) >>>>> 66. IMPLEMENT_DYNAMIC_CHECK_FN() >>>>> >>>>> >>>>> ============================================================================== >>>>> >>>>> Regards, >>>>> Shariful Alam >>>>> >>>>> >>>> >>>> -- >>>> SY, Dmitry Belyavsky >>>> >>> >> >> -- >> SY, Dmitry Belyavsky >> > > > -- > SY, Dmitry Belyavsky > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kory at avatarci.com Tue Oct 5 22:49:48 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Tue, 5 Oct 2021 15:49:48 -0700 Subject: OpenSSL 3.0.0 enabling SSLv3 support Message-ID: <30EB9A1D-8DA2-4DC0-8619-16C865056DA9@avatarci.com> Hi, It looks like SSLv3 is not built by default in OpenSSL 3.0.0. At least SSLv3_method() is not define, and looking at the conditional compilation of that function, it makes sense. What command line option do I pass the Configure script to enable it? I tried enable-sslv3 and enable-SSLv3. It complained about both. I need to compile some old code (Python 2.7) which we will abandon soon. Thanks, Kory From openssl-users at dukhovni.org Wed Oct 6 00:09:31 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 5 Oct 2021 20:09:31 -0400 Subject: OpenSSL 3.0.0 enabling SSLv3 support In-Reply-To: <30EB9A1D-8DA2-4DC0-8619-16C865056DA9@avatarci.com> References: <30EB9A1D-8DA2-4DC0-8619-16C865056DA9@avatarci.com> Message-ID: On Tue, Oct 05, 2021 at 03:49:48PM -0700, Kory Hamzeh wrote: > It looks like SSLv3 is not built by default in OpenSSL 3.0.0. At least > SSLv3_method() is not define, and looking at the conditional > compilation of that function, it makes sense. > > What command line option do I pass the Configure script to enable it? > I tried enable-sslv3 and enable-SSLv3. It complained about both. I > need to compile some old code (Python 2.7) which we will abandon soon. Don't enable SSLv3 in OpenSSL 3.0, that's not doing anyone a favour. Better to instead build the code in question against OpenSSL 1.1.1, if SSLv3 actually needs to be *used*. It is not a problem to install both OpenSSL 1.1.1 and OpenSSL 3.0 side-by-side (shared libraries) on systems with support for symbol versioning. If the only purpose of SSLv3 is to get code to compile, that will not in fact ever run, or that can reasonably just return an error when it runs, you can enable the method stubs, without enabling support for the protocol: ./Configure enable-ssl3-method ... The default is to disable both "ssl3" and "ssl3-protocol" and I would strongly encourage you to not enable both. Nobody should be actually using SSLv3 anymore, but exporting function stubs that will error out makes some sense if required to support toolkits that wrap the OpenSSL API and still want to expose SSLv3 methods. -- Viktor. From sujiknair at gmail.com Wed Oct 6 05:46:55 2021 From: sujiknair at gmail.com (Suji) Date: Wed, 6 Oct 2021 11:16:55 +0530 Subject: Issue with API EVP_PKEY_new_CMAC_key Message-ID: Hi, I am getting an issue with EVP_PKEY_new_CMAC_key while using Engine as an argument. It was a negative test case, passed an invalid key length. It hits the error, and when the application exits , it gets a segmentation fault. >From my analysis, the scenario seems like this. When the call happens engine reference count e-funct_ref increases by 1 (CMAC_CTX_new) but when this error occurs it is decreased by 2 (EVP_PKEY_free and CMAC_CTX_free). When the application exits it again tries for EVP_PKEY_free and this issue happens.The call never reaches the engine, as it is an error case. It seems a bug to me, as one of these EVP_PKEY_free should be avoided. Any analysis on this? Thanks, Suji -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 6 07:55:44 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 6 Oct 2021 08:55:44 +0100 Subject: Issue with API EVP_PKEY_new_CMAC_key In-Reply-To: References: Message-ID: On 06/10/2021 06:46, Suji wrote: > Hi, > > I am getting an issue with EVP_PKEY_new_CMAC_key while using Engine as > an argument. It was a negative test case, passed an invalid key length. > It hits the error, and when the application exits , it gets a > segmentation fault. > > From my analysis, the scenario seems like this. When the call happens > engine reference count e-funct_ref increases by 1 (CMAC_CTX_new) but > when this error occurs it is decreased by 2 (EVP_PKEY_free and > CMAC_CTX_free). When the application exits it again tries for > EVP_PKEY_free and this issue happens.The call never reaches the engine, > as it is an error case. > > It seems a bug to me, as one of these EVP_PKEY_free should be avoided. > Any analysis on this? This looks like a bug to me. It seems to me that the internal function pkey_set_type() is consuming the ENGINE reference when it should not do so. This means when we come to free things up, we free up one too many references. I've raised an issue for it here: https://github.com/openssl/openssl/issues/16757 Matt From Sunil.Paramashivaiah at rbbn.com Wed Oct 6 13:08:50 2021 From: Sunil.Paramashivaiah at rbbn.com (Paramashivaiah, Sunil) Date: Wed, 6 Oct 2021 13:08:50 +0000 Subject: Providers in OPENSSL 3.0 to replace Third Party Engine(OPENSSL 1.0.2) Message-ID: Hi All, We are migrating our application to use OPENSSL 3.0 from OPENSSL 1.0.2. We have ENGINE related code which loads a third party lib.so as engine. We are using the below set of deprecated API's for that. ENGINE_load_dynamic(),ENGINE_by_id("dynamic"),ENGINE_ctrl_cmd_string(e, "SO_PATH", lib.c_str(), 0). Now in OPENSSL 3.0 as we understand we need to use PROVIDERS to achieve the above functionality. We found API OSSL_PROVIDER_load() to load and initialize the provider. Can we use the same lib.so which we were using for ENGINE to replace it as provider and Please let us know how we can use it in OSSL_PROVIDER_load() API to load a third party lib.so. Thanks and Regards, Sunil Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 6 13:12:31 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 6 Oct 2021 14:12:31 +0100 Subject: Providers in OPENSSL 3.0 to replace Third Party Engine(OPENSSL 1.0.2) In-Reply-To: References: Message-ID: On 06/10/2021 14:08, Paramashivaiah, Sunil wrote: > ?????Can we use the same lib.so which we were using for ENGINE to > replace it as provider No. The OpenSSL <-> Engine interface is completely different to the OpenSSL <-> Provider interface. You need to ask the supplier of your ENGINE to update it to a provider (for which you will need a new .so file). Until then you are stuck using the deprecated ENGINE interfaces. Matt From kory at avatarci.com Wed Oct 6 18:25:33 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Wed, 6 Oct 2021 11:25:33 -0700 Subject: OpenSSL 3.0.0 enabling SSLv3 support In-Reply-To: References: <30EB9A1D-8DA2-4DC0-8619-16C865056DA9@avatarci.com> Message-ID: Fair enough. We are not using SSLv3, the code just made reference to the method. I will compile it out. Thanks! > On Oct 5, 2021, at 5:09 PM, Viktor Dukhovni wrote: > > On Tue, Oct 05, 2021 at 03:49:48PM -0700, Kory Hamzeh wrote: > >> It looks like SSLv3 is not built by default in OpenSSL 3.0.0. At least >> SSLv3_method() is not define, and looking at the conditional >> compilation of that function, it makes sense. >> >> What command line option do I pass the Configure script to enable it? >> I tried enable-sslv3 and enable-SSLv3. It complained about both. I >> need to compile some old code (Python 2.7) which we will abandon soon. > > Don't enable SSLv3 in OpenSSL 3.0, that's not doing anyone a favour. > Better to instead build the code in question against OpenSSL 1.1.1, if > SSLv3 actually needs to be *used*. It is not a problem to install both > OpenSSL 1.1.1 and OpenSSL 3.0 side-by-side (shared libraries) on systems > with support for symbol versioning. > > If the only purpose of SSLv3 is to get code to compile, that will not > in fact ever run, or that can reasonably just return an error when > it runs, you can enable the method stubs, without enabling support > for the protocol: > > ./Configure enable-ssl3-method ... > > The default is to disable both "ssl3" and "ssl3-protocol" and I would > strongly encourage you to not enable both. Nobody should be actually > using SSLv3 anymore, but exporting function stubs that will error out > makes some sense if required to support toolkits that wrap the OpenSSL > API and still want to expose SSLv3 methods. > > -- > Viktor. From Shivakumar.Poojari at rbbn.com Thu Oct 7 07:18:37 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Thu, 7 Oct 2021 07:18:37 +0000 Subject: [EXTERNAL] Re: Replacement for BIO_get_port(), BIO_get_host_ip() In-Reply-To: References: Message-ID: Hi Matt, The steps suggested are similarly to the deprecated function so simply I used the same code in static function, But i need support for IPV6 as well in the same function The function needs to have compatibility to support for both ipv6 and ipv4, do we have any new function to support both thanks, Shivakumar. ________________________________ From: Matt Caswell Sent: Monday, September 27, 2021 3:05 PM To: Shivakumar Poojari ; openssl-users at openssl.org Cc: Paramashivaiah, Sunil Subject: [EXTERNAL] Re: Replacement for BIO_get_port(), BIO_get_host_ip() On 24/09/2021 07:05, Shivakumar Poojari wrote: > Hi > BIO_get_port(), BIO_get_host_ip(), were deprecated in OpenSSL 1.1.0. > Trying for replacement for OpenSSl 3.0 > > Gone through the below man page, but not found alternative function. > > https://clicktime.symantec.com/3Xv8ZiB6xAtjRGsCNHevANW6H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fmanmaster%2Fman3%2FBIO_connect.html > > > please suggest, These functions are deprecated because they only support IPv4. Instead you can use BIO_lookup() (or possibly BIO_lookup_ex()) to lookup the given host/service (first and second parameters to BIO_lookup() respectively). Equivalent 3rd/4th/5th parameters to BIO_lookup() might be BIO_LOOKUP_CLIENT, AF_INET (for IPv4) and SOCK_STREAM (for TCP). This will return you an initialised BIO_ADDRINFO() object (which you will have to later free using BIO_ADDRINFO_free()). From the BIO_ADDRINFO object you can get a pointer to an underlying BIO_ADDR using BIO_ADDRINFO_address(addrinfo). Finally you can use BIO_ADDR_rawaddress() to get address info, or BIO_ADDR_rawport() to get port info: See: https://clicktime.symantec.com/3EBngctzbwbGZ7EtRw3Ks6N6H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FBIO_lookup.html https://clicktime.symantec.com/33SMrAMvMeCpangnxBCzSv96H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FBIO_ADDR_rawaddress.html Matt Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From santantonioswap at gmail.com Thu Oct 7 07:49:52 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Thu, 7 Oct 2021 08:49:52 +0100 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> <033cf963496decbca923af5d8ba4b1781ac1fd65.camel@openssl.org> Message-ID: Hello, just continuing on this.. I defined my store mgmt as : static const OSSL_ALGORITHM test_store[] = { { "handle", "provider=test", mystore_functions}, {NULL, NULL, NULL} }; echo "test" | LD_LIBRARY_PATH=. apps/openssl dgst --provider-path=./providers --provider=test --sign handle:1 -out messa.encrypted.bin Could not open file or uri for loading private key from handle:1 C0628C24787F0000:error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto/store/store_register.c:237:scheme=file C0628C24787F0000:error:1608010C:STORE routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No store loader found. For standard store loaders you need at least one of the default or base providers available. Did you forget to load them? Info: Global default library context, Scheme (file : 0), Properties () C0628C24787F0000:error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto/store/store_register.c:237:scheme=handle 1) It firstly looks for a provider for scheme file: and it doesn't find as I haven't set up any store mgmt for file: . 2) It looks like on second attempt it tries to look for handle: but it finds it not registered. What does this error mean ? Does it look for registered uri schemes online ? if that is the case how can this works instead : https://github.com/tpm2-software/tpm2-openssl ? They use handle: scheme as well. Does this mean it's a problem of the methods I registered for the store or is something related to the uri scheme I am using ? Sorry but I couldn't find more info on this in the sources/docs . thank you On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana wrote: > > OK, thank you very much for your comments, that's clear. > > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote: >> >> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already >> modified to use OSSL_STORE API to load keys. So you do not need to >> specify keyform=ENGINE if your key is provided by a provider that >> supports the STORE functionality for some special URL scheme. You just >> specify the right URL with that scheme to reference the key in the >> provider. >> >> Of course third party applications need to be modified to call >> OSSL_STORE API in a similar way how the openssl application does it. >> >> Tomas >> >> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: >> > Thank you for your comment. >> > Am I wrong then in saying that dgst and possibly other apps are not >> > ready to be used with providers rather than engines in the case you >> > need keyform=ENGINE ? >> > >> > >> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: >> > > You would have to implement a STORE provider that handles your >> > > special >> > > url scheme and then the keys would be referenced by the >> > > yourscheme://any-identifier-you-have. Of course the application >> > > (i.e., >> > > the openssl application which already does this) would have to use >> > > the >> > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER >> > > API >> > > or the d2i/PEM_read APIs. >> > > >> > > Tomas >> > > >> > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: >> > > > I checked the sources, I found that keyform cannot be set to >> > > > ENGINE >> > > > if engine is not specified in the command options, this is in the >> > > > function make_engine_url() called from load_key() when >> > > > format==FORMAT_ENGINE. >> > > > I am not specifying engine in the dgst command options as I am >> > > using >> > > > a provider. >> > > > I would like to achieve the same as FORMAT_ENGINE does, but with >> > > > provider. >> > > > >> > > > >> > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, >> > > > wrote: >> > > > > Hello, >> > > > > I am doing my own provider starting from the default provider's >> > > > > code. >> > > > > I have now a question, I am seeing the STOREMGMT operation is >> > > > > required to interpret the URI of input private key, I would >> > > > > like >> > > > > that the string passed by the user for input key is not >> > > > > interpret >> > > > > as file to open but just my provider should save the string >> > > > > value >> > > > > to be used later .This is when invoking command options such >> > > > > as >> > > > > dgst sign -in "text" -keyform ENG. >> > > > > With engines' architecture this is possible by passing option - >> > > > > keyform ENG to dgst command. The string in that case is not >> > > > > interpreted as a file path and just passed through. >> > > > > There was engine_set_load_privkey_function that was getting >> > > > > this >> > > > > string. >> > > > > How can I achieve this now with the provider architecture ? If >> > > > > I >> > > > > pass -keyform ENG to dgst command together with --provider , it >> > > > > says "no engine specified to load private key" Should I use >> > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . >> > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I >> > > don't >> > > > > have a real private key info to load and use from a Filesystem. >> > > > > Is there anything to set in the KEYMGMT too ? I can see there >> > > > > is >> > > a >> > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key >> > > > > data in a key object should be considered. Not really sure if >> > > this >> > > > > is something I should set or not and how this keymgmt operation >> > > > > relates with storemgmt operation. >> > > > > >> > > > > thank you if you can send some comment on this. >> > > > > >> > > >> >> -- >> Tom?? Mr?z >> No matter how far down the wrong road you've gone, turn back. >> Turkish proverb >> [You'll know whether the road is wrong if you carefully listen to your >> conscience.] >> >> From matt at openssl.org Thu Oct 7 08:26:05 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 7 Oct 2021 09:26:05 +0100 Subject: [EXTERNAL] Re: Replacement for BIO_get_port(), BIO_get_host_ip() In-Reply-To: References: Message-ID: <1bb233c2-8b9b-8c7e-9a73-fd165b1ecdfa@openssl.org> The functions I suggested support both IPv4 and IPv6. For example in the BIO_lookup() call the 4th parameter would be AF_INET for IPv4 and AF_INET6 for IPv6. Matt On 07/10/2021 08:18, Shivakumar Poojari wrote: > Hi?Matt, > The steps suggested are similarly to the deprecated function so simply > I used the same code in static function, But i need support for IPV6 as > well in the same function > > The function needs to have compatibility to support for both ipv6 and > ipv4, do we have any new function to support both > > > thanks, > Shivakumar. > ------------------------------------------------------------------------ > *From:* Matt Caswell > *Sent:* Monday, September 27, 2021 3:05 PM > *To:* Shivakumar Poojari ; > openssl-users at openssl.org > *Cc:* Paramashivaiah, Sunil > *Subject:* [EXTERNAL] Re: Replacement for BIO_get_port(), BIO_get_host_ip() > > > On 24/09/2021 07:05, Shivakumar Poojari wrote: >> Hi >> BIO_get_port(), BIO_get_host_ip(),? were deprecated in OpenSSL 1.1.0. >> Trying for replacement for OpenSSl 3.0 >> >> Gone through the below man page, but not found alternative function. >> >> https://clicktime.symantec.com/3Xv8ZiB6xAtjRGsCNHevANW6H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fmanmaster%2Fman3%2FBIO_connect.html > > >> > >> >> please suggest, > > These functions are deprecated because they only support IPv4. > > Instead you can use BIO_lookup() (or possibly BIO_lookup_ex()) to lookup > the given host/service (first and second parameters to BIO_lookup() > respectively). Equivalent 3rd/4th/5th parameters to BIO_lookup() might > be BIO_LOOKUP_CLIENT, AF_INET (for IPv4) and SOCK_STREAM (for TCP). > > This will return you an initialised BIO_ADDRINFO() object (which you > will have to later free using BIO_ADDRINFO_free()). > > ?From the BIO_ADDRINFO object you can get a pointer to an underlying > BIO_ADDR using BIO_ADDRINFO_address(addrinfo). Finally you can use > BIO_ADDR_rawaddress() to get address info, or BIO_ADDR_rawport() to get > port info: > > See: > https://clicktime.symantec.com/3EBngctzbwbGZ7EtRw3Ks6N6H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FBIO_lookup.html > > https://clicktime.symantec.com/33SMrAMvMeCpangnxBCzSv96H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FBIO_ADDR_rawaddress.html > > > Matt > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. From santantonioswap at gmail.com Thu Oct 7 08:47:59 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Thu, 7 Oct 2021 09:47:59 +0100 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> <033cf963496decbca923af5d8ba4b1781ac1fd65.camel@openssl.org> Message-ID: It is because of prototypes of methods.. On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, wrote: > Hello, > just continuing on this.. > I defined my store mgmt as : > static const OSSL_ALGORITHM test_store[] = { > { "handle", "provider=test", mystore_functions}, > {NULL, NULL, NULL} > }; > > echo "test" | LD_LIBRARY_PATH=. apps/openssl dgst > --provider-path=./providers --provider=test --sign handle:1 -out > messa.encrypted.bin > > Could not open file or uri for loading private key from handle:1 > > C0628C24787F0000:error:16000069:STORE > routines:ossl_store_get0_loader_int:unregistered > scheme:crypto/store/store_register.c:237:scheme=file > > C0628C24787F0000:error:1608010C:STORE > routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No > store loader found. For standard store loaders you need at least one > of the default or base providers available. Did you forget to load > them? Info: Global default library context, Scheme (file : 0), > Properties () > > C0628C24787F0000:error:16000069:STORE > routines:ossl_store_get0_loader_int:unregistered > scheme:crypto/store/store_register.c:237:scheme=handle > > 1) It firstly looks for a provider for scheme file: and it doesn't > find as I haven't set up any store mgmt for file: . > > 2) It looks like on second attempt it tries to look for handle: but it > finds it not registered. What does this error mean ? Does it look for > registered uri schemes online ? if that is the case how can this works > instead : https://github.com/tpm2-software/tpm2-openssl ? They use > handle: scheme as well. > > Does this mean it's a problem of the methods I registered for the > store or is something related to the uri scheme I am using ? > Sorry but I couldn't find more info on this in the sources/docs . > > > thank you > > > > On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana > wrote: > > > > OK, thank you very much for your comments, that's clear. > > > > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote: > >> > >> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already > >> modified to use OSSL_STORE API to load keys. So you do not need to > >> specify keyform=ENGINE if your key is provided by a provider that > >> supports the STORE functionality for some special URL scheme. You just > >> specify the right URL with that scheme to reference the key in the > >> provider. > >> > >> Of course third party applications need to be modified to call > >> OSSL_STORE API in a similar way how the openssl application does it. > >> > >> Tomas > >> > >> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: > >> > Thank you for your comment. > >> > Am I wrong then in saying that dgst and possibly other apps are not > >> > ready to be used with providers rather than engines in the case you > >> > need keyform=ENGINE ? > >> > > >> > > >> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: > >> > > You would have to implement a STORE provider that handles your > >> > > special > >> > > url scheme and then the keys would be referenced by the > >> > > yourscheme://any-identifier-you-have. Of course the application > >> > > (i.e., > >> > > the openssl application which already does this) would have to use > >> > > the > >> > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER > >> > > API > >> > > or the d2i/PEM_read APIs. > >> > > > >> > > Tomas > >> > > > >> > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: > >> > > > I checked the sources, I found that keyform cannot be set to > >> > > > ENGINE > >> > > > if engine is not specified in the command options, this is in the > >> > > > function make_engine_url() called from load_key() when > >> > > > format==FORMAT_ENGINE. > >> > > > I am not specifying engine in the dgst command options as I am > >> > > using > >> > > > a provider. > >> > > > I would like to achieve the same as FORMAT_ENGINE does, but with > >> > > > provider. > >> > > > > >> > > > > >> > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, > >> > > > wrote: > >> > > > > Hello, > >> > > > > I am doing my own provider starting from the default provider's > >> > > > > code. > >> > > > > I have now a question, I am seeing the STOREMGMT operation is > >> > > > > required to interpret the URI of input private key, I would > >> > > > > like > >> > > > > that the string passed by the user for input key is not > >> > > > > interpret > >> > > > > as file to open but just my provider should save the string > >> > > > > value > >> > > > > to be used later .This is when invoking command options such > >> > > > > as > >> > > > > dgst sign -in "text" -keyform ENG. > >> > > > > With engines' architecture this is possible by passing option - > >> > > > > keyform ENG to dgst command. The string in that case is not > >> > > > > interpreted as a file path and just passed through. > >> > > > > There was engine_set_load_privkey_function that was getting > >> > > > > this > >> > > > > string. > >> > > > > How can I achieve this now with the provider architecture ? If > >> > > > > I > >> > > > > pass -keyform ENG to dgst command together with --provider , it > >> > > > > says "no engine specified to load private key" Should I use > >> > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . > >> > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I > >> > > don't > >> > > > > have a real private key info to load and use from a Filesystem. > >> > > > > Is there anything to set in the KEYMGMT too ? I can see there > >> > > > > is > >> > > a > >> > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key > >> > > > > data in a key object should be considered. Not really sure if > >> > > this > >> > > > > is something I should set or not and how this keymgmt operation > >> > > > > relates with storemgmt operation. > >> > > > > > >> > > > > thank you if you can send some comment on this. > >> > > > > > >> > > > >> > >> -- > >> Tom?? Mr?z > >> No matter how far down the wrong road you've gone, turn back. > >> Turkish proverb > >> [You'll know whether the road is wrong if you carefully listen to your > >> conscience.] > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markhack at markhack.com Thu Oct 7 14:38:30 2021 From: markhack at markhack.com (Mark Hack) Date: Thu, 07 Oct 2021 09:38:30 -0500 Subject: OpenSSL 3.0.0 enabling SSLv3 support In-Reply-To: References: <30EB9A1D-8DA2-4DC0-8619-16C865056DA9@avatarci.com> Message-ID: <57a50104dbd5ef6f1dd2969524f60c14e173ecbc.camel@markhack.com> Added to all the weaknesses in SSLv3, the only supported cipher suites are either vulnerable or deprecated and not advisable. SSL_RSA_WITH_NULL_MD5 NULL-MD5 SSL_RSA_WITH_NULL_SHA NULL-SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 EXP-RC4-MD5 SSL_RSA_WITH_RC4_128_MD5 RC4-MD5 SSL_RSA_WITH_RC4_128_SHA RC4-SHA SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 EXP-RC2-CBC-MD5 SSL_RSA_WITH_IDEA_CBC_SHA IDEA-CBC-SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-DES-CBC-SHA SSL_RSA_WITH_DES_CBC_SHA DES-CBC-SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA SSL_DH_DSS_WITH_DES_CBC_SHA DH-DSS-DES-CBC-SHA SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA DH-DSS-DES-CBC3-SHA SSL_DH_RSA_WITH_DES_CBC_SHA DH-RSA-DES-CBC-SHA SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA DH-RSA-DES-CBC3-SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-DSS-DES-CBC-SHA SSL_DHE_DSS_WITH_DES_CBC_SHA EDH-DSS-CBC-SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA EDH-DSS-DES-CBC3-SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA EXP-EDH-RSA-DES-CBC-SHA SSL_DHE_RSA_WITH_DES_CBC_SHA EDH-RSA-DES-CBC-SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA EDH-RSA-DES-CBC3-SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 EXP-ADH-RC4-MD5 SSL_DH_anon_WITH_RC4_128_MD5 ADH-RC4-MD5 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA EXP-ADH-DES-CBC-SHA SSL_DH_anon_WITH_DES_CBC_SHA ADH-DES-CBC-SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA ADH-DES-CBC3-SHA SSL_FORTEZZA_KEA_WITH_NULL_SHA Not implemented. SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA Not implemented. SSL_FORTEZZA_KEA_WITH_RC4_128_SHA Not implemented. On Wed, 2021-10-06 at 11:25 -0700, Kory Hamzeh wrote: > Fair enough. We are not using SSLv3, the code just made reference to > the method. I will compile it out. > > Thanks! > > > > On Oct 5, 2021, at 5:09 PM, Viktor Dukhovni < > > openssl-users at dukhovni.org> wrote: > > > > On Tue, Oct 05, 2021 at 03:49:48PM -0700, Kory Hamzeh wrote: > > > > > It looks like SSLv3 is not built by default in OpenSSL 3.0.0. At > > > least > > > SSLv3_method() is not define, and looking at the conditional > > > compilation of that function, it makes sense. > > > > > > What command line option do I pass the Configure script to enable > > > it? > > > I tried enable-sslv3 and enable-SSLv3. It complained about both. > > > I > > > need to compile some old code (Python 2.7) which we will abandon > > > soon. > > > > Don't enable SSLv3 in OpenSSL 3.0, that's not doing anyone a > > favour. > > Better to instead build the code in question against OpenSSL 1.1.1, > > if > > SSLv3 actually needs to be *used*. It is not a problem to install > > both > > OpenSSL 1.1.1 and OpenSSL 3.0 side-by-side (shared libraries) on > > systems > > with support for symbol versioning. > > > > If the only purpose of SSLv3 is to get code to compile, that will > > not > > in fact ever run, or that can reasonably just return an error when > > it runs, you can enable the method stubs, without enabling support > > for the protocol: > > > > ./Configure enable-ssl3-method ... > > > > The default is to disable both "ssl3" and "ssl3-protocol" and I > > would > > strongly encourage you to not enable both. Nobody should be > > actually > > using SSLv3 anymore, but exporting function stubs that will error > > out > > makes some sense if required to support toolkits that wrap the > > OpenSSL > > API and still want to expose SSLv3 methods. > > > > -- > > Viktor. > > From openssl-users at dukhovni.org Thu Oct 7 15:53:02 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 7 Oct 2021 11:53:02 -0400 Subject: OpenSSL 3.0.0 enabling SSLv3 support In-Reply-To: <57a50104dbd5ef6f1dd2969524f60c14e173ecbc.camel@markhack.com> References: <30EB9A1D-8DA2-4DC0-8619-16C865056DA9@avatarci.com> <57a50104dbd5ef6f1dd2969524f60c14e173ecbc.camel@markhack.com> Message-ID: On Thu, Oct 07, 2021 at 09:38:30AM -0500, Mark Hack wrote: > Added to all the weaknesses in SSLv3, the only supported cipher suites > are either vulnerable or deprecated and not advisable. If we set aside browsers where CBC padding oracles are a problem, the below are in practice still reasonably strong in most other applications. ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 And yet, SSLv3 should still not be used, because it does not support extensions, so no SNI, no protection against insecure renegotiation, ... -- Viktor. From pauli at openssl.org Fri Oct 8 00:09:09 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Fri, 8 Oct 2021 10:09:09 +1000 Subject: OpenSSL 3.0.0 FIPS compatible ECDH-KAS In-Reply-To: <7E9D3B45-A789-4234-9B18-9D62FF9961FB@avatarci.com> References: <275ce773-30a8-4382-66a6-2b2375cc73bb@openssl.org> <6c9d6ce6-70c2-c0cd-53f2-70e737ec7774@openssl.org> <7E9D3B45-A789-4234-9B18-9D62FF9961FB@avatarci.com> Message-ID: <734f4759-f630-f95c-ed93-04aebbf2f6b7@openssl.org> Kory, The situation is more complicated but your solution below is the one I'd have suggested. SP800-90B says bad things about /dev/random but this is modified by IG 7.14 indicates that it is okay to use /dev/random. Then IG 7.19 says that it isn't.? The current FIPS 140-2 validation is sidestepping the ongoing changes to the standards and mandates by placing the entropy collection outside the FIPS boundary.? This will incur a caveat but it is the best we could hope for given the variety of platforms being validated and the rate of change of the commandments. Pauli On 8/10/21 6:23 am, Kory Hamzeh wrote: > Hi Pauli, > > I had some success by doing this: > > > static const OSSL_ALGORITHM sc4k_rands[] = { > { "SC4K-SEED-SRC", "fips=yes", sc4k_seed_src_functions }, > { NULL, NULL, NULL } > }; > > and passing ?fips=yes? when I set the seed source. > > I am still curious to know is the FIPS module uses providers/implementations/rands/seed_src.c to seed the RNG. My understanding is that /dev/random is not secure enough per NIST SP-800-90B. > > Sorry I picked the wrong message thread for these questions. This is about my custom entropy source that you helped ne with. > > Thanks, > Kory > > > . >> On Oct 7, 2021, at 11:19 AM, Kory Hamzeh wrote: >> >> Hi Pauli, >> >> Running into a strange problem. My custom seed source works fine, but if I call: >> EVP_set_default_properties(NULL, "fips=yes"); >> >> Then my seed source is not used. Does FIPS have its own seed source? The whole purpose of this exercise was to create a NIST SP-800-90B compliant entropy source for FIPS. >> >> Thanks, >> Kory >> >> >>> On Sep 22, 2021, at 3:51 PM, Dr Paul Dale wrote: >>> >>> If you are only using functions that are deprecated, you'll get away without for the moment. >>> >>> Pauli >>> >>> On 23/9/21 8:45 am, Kory Hamzeh wrote: >>>> Hi Pauli, >>>> >>>> Thanks for the reply. Yes, I have loaded the base and fips providers. >>>> >>>> But just to clarify, I still need to rewrite to low-level code to use the EVP code, correct? >>>> >>>> Thanks, >>>> Kory >>>> >>>> >>>>> On Sep 22, 2021, at 3:29 PM, Dr Paul Dale wrote: >>>>> >>>>> Adding that should be enough to force only FIPS validated algorithms are used. >>>>> >>>>> Just doing that isn't enough, there is more you are going to need to do. E.g. you will need to load the FIPS and base providers either via config or explicitly. >>>>> >>>>> It's possible to set the default properties via config too. >>>>> >>>>> >>>>> Everything is documented and I'd recommend starting with the migration guide manual page and working from there. >>>>> >>>>> In my opinion, the 1.0 -> 1.1 transition is the more onerous part. >>>>> >>>>> >>>>> Pauli >>>>> >>>>> On 23/9/21 3:44 am, Kory Hamzeh wrote: >>>>>> I have an OpenSSL app which performs ECDH-KAS using openssl-1.0.1g + openssl-fips-2.0.5. It needs to be FIPS compatible. The app was written using the low level ECDH functions similar to what is documented here: >>>>>> >>>>>> https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman#Using_the_Low_Level_APIs >>>>>> >>>>>> According to the OpenSSL 3.0.0 Wiki, I MUST rewrite my code to use the high level EVP functions if I want FIPS compatibility. If so, I was going to follow the EVP example at the top of the same URL above. >>>>>> >>>>>> However, I can use some help. Using the EVP example on that page, when and which methods do I need to fetch? If I just add this at the top: >>>>>> >>>>>> EVP_set_default_properties(NULL, "fips=yes?); >>>>>> >>>>>> will that be enough? >>>>>> >>>>>> Thanks, >>>>>> Kory >>>>>> >>>>>> >>>>>> >>>>>> From Sunil.Paramashivaiah at rbbn.com Fri Oct 8 05:21:53 2021 From: Sunil.Paramashivaiah at rbbn.com (Paramashivaiah, Sunil) Date: Fri, 8 Oct 2021 05:21:53 +0000 Subject: API to get BIGNUM member "top" in openssl 3.0 Message-ID: Hi All, In our application we are accessing BIGNUM member top as bn->top. Now we are trying to migrate to OPENSSL 3.0. I am unable to find API to access this member. Please let me know if there is any get API to get the "top" member of BIGNUM. Thanks and Regards, Sunil Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bbrumley at gmail.com Fri Oct 8 05:42:01 2021 From: bbrumley at gmail.com (Billy Brumley) Date: Fri, 8 Oct 2021 08:42:01 +0300 Subject: API to get BIGNUM member "top" in openssl 3.0 In-Reply-To: References: Message-ID: > In our application we are accessing BIGNUM member top as bn->top. Now we are trying > > to migrate to OPENSSL 3.0. I am unable to find API to access this member. > > Please let me know if there is any get API to get the ?top? member of BIGNUM. Since the structure is opaque, I can't imagine _really_ needing access to ->top since that is a BIGNUM-internal concept. Can you give a MWE for what you are trying to achieve? Cheers, BBB From Matthias.St.Pierre at ncp-e.com Fri Oct 8 05:56:47 2021 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 8 Oct 2021 05:56:47 +0000 Subject: API to get BIGNUM member "top" in openssl 3.0 In-Reply-To: References: Message-ID: <3856680c276a4ddf80a5ab475c75b798@ncp-e.com> > Can you give a MWE for what you are trying to achieve? I guess that "minimal working example" is the correct choice from the gazillions of possible meanings of "MWE"? ? Regards, Matthias [1] https://www.acronymattic.com/MWE.html [2] https://www.abbreviations.com/MWE -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7448 bytes Desc: not available URL: From santantonioswap at gmail.com Fri Oct 8 08:34:33 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Fri, 8 Oct 2021 09:34:33 +0100 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> <033cf963496decbca923af5d8ba4b1781ac1fd65.camel@openssl.org> Message-ID: Could I ask you what is the best way to let the Openssl carry on in the case I can't pass the private key from my store manager load() function as key is offloaded in secure hw? I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the callback function from my Store Mgmt's load() where I get the uri ( the callback func is ossl_store_handle_load_result() ) I get error "could not read the private key". If instead I call the callback func , I don't know how to fill in its params , as I don't have the private key. What should I put in the params to let the rest of call chain ( I am on the dgst command ) not caring about private key but carry on with operation?or can I avoid calling the callback? Thank you On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana, wrote: > It is because of prototypes of methods.. > > On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, < > santantonioswap at gmail.com> wrote: > >> Hello, >> just continuing on this.. >> I defined my store mgmt as : >> static const OSSL_ALGORITHM test_store[] = { >> { "handle", "provider=test", mystore_functions}, >> {NULL, NULL, NULL} >> }; >> >> echo "test" | LD_LIBRARY_PATH=. apps/openssl dgst >> --provider-path=./providers --provider=test --sign handle:1 -out >> messa.encrypted.bin >> >> Could not open file or uri for loading private key from handle:1 >> >> C0628C24787F0000:error:16000069:STORE >> routines:ossl_store_get0_loader_int:unregistered >> scheme:crypto/store/store_register.c:237:scheme=file >> >> C0628C24787F0000:error:1608010C:STORE >> routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No >> store loader found. For standard store loaders you need at least one >> of the default or base providers available. Did you forget to load >> them? Info: Global default library context, Scheme (file : 0), >> Properties () >> >> C0628C24787F0000:error:16000069:STORE >> routines:ossl_store_get0_loader_int:unregistered >> scheme:crypto/store/store_register.c:237:scheme=handle >> >> 1) It firstly looks for a provider for scheme file: and it doesn't >> find as I haven't set up any store mgmt for file: . >> >> 2) It looks like on second attempt it tries to look for handle: but it >> finds it not registered. What does this error mean ? Does it look for >> registered uri schemes online ? if that is the case how can this works >> instead : https://github.com/tpm2-software/tpm2-openssl ? They use >> handle: scheme as well. >> >> Does this mean it's a problem of the methods I registered for the >> store or is something related to the uri scheme I am using ? >> Sorry but I couldn't find more info on this in the sources/docs . >> >> >> thank you >> >> >> >> On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana >> wrote: >> > >> > OK, thank you very much for your comments, that's clear. >> > >> > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote: >> >> >> >> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already >> >> modified to use OSSL_STORE API to load keys. So you do not need to >> >> specify keyform=ENGINE if your key is provided by a provider that >> >> supports the STORE functionality for some special URL scheme. You just >> >> specify the right URL with that scheme to reference the key in the >> >> provider. >> >> >> >> Of course third party applications need to be modified to call >> >> OSSL_STORE API in a similar way how the openssl application does it. >> >> >> >> Tomas >> >> >> >> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: >> >> > Thank you for your comment. >> >> > Am I wrong then in saying that dgst and possibly other apps are not >> >> > ready to be used with providers rather than engines in the case you >> >> > need keyform=ENGINE ? >> >> > >> >> > >> >> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: >> >> > > You would have to implement a STORE provider that handles your >> >> > > special >> >> > > url scheme and then the keys would be referenced by the >> >> > > yourscheme://any-identifier-you-have. Of course the application >> >> > > (i.e., >> >> > > the openssl application which already does this) would have to use >> >> > > the >> >> > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER >> >> > > API >> >> > > or the d2i/PEM_read APIs. >> >> > > >> >> > > Tomas >> >> > > >> >> > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: >> >> > > > I checked the sources, I found that keyform cannot be set to >> >> > > > ENGINE >> >> > > > if engine is not specified in the command options, this is in the >> >> > > > function make_engine_url() called from load_key() when >> >> > > > format==FORMAT_ENGINE. >> >> > > > I am not specifying engine in the dgst command options as I am >> >> > > using >> >> > > > a provider. >> >> > > > I would like to achieve the same as FORMAT_ENGINE does, but with >> >> > > > provider. >> >> > > > >> >> > > > >> >> > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, >> >> > > > wrote: >> >> > > > > Hello, >> >> > > > > I am doing my own provider starting from the default provider's >> >> > > > > code. >> >> > > > > I have now a question, I am seeing the STOREMGMT operation is >> >> > > > > required to interpret the URI of input private key, I would >> >> > > > > like >> >> > > > > that the string passed by the user for input key is not >> >> > > > > interpret >> >> > > > > as file to open but just my provider should save the string >> >> > > > > value >> >> > > > > to be used later .This is when invoking command options such >> >> > > > > as >> >> > > > > dgst sign -in "text" -keyform ENG. >> >> > > > > With engines' architecture this is possible by passing option - >> >> > > > > keyform ENG to dgst command. The string in that case is not >> >> > > > > interpreted as a file path and just passed through. >> >> > > > > There was engine_set_load_privkey_function that was getting >> >> > > > > this >> >> > > > > string. >> >> > > > > How can I achieve this now with the provider architecture ? If >> >> > > > > I >> >> > > > > pass -keyform ENG to dgst command together with --provider , it >> >> > > > > says "no engine specified to load private key" Should I use >> >> > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . >> >> > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I >> >> > > don't >> >> > > > > have a real private key info to load and use from a Filesystem. >> >> > > > > Is there anything to set in the KEYMGMT too ? I can see there >> >> > > > > is >> >> > > a >> >> > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key >> >> > > > > data in a key object should be considered. Not really sure if >> >> > > this >> >> > > > > is something I should set or not and how this keymgmt operation >> >> > > > > relates with storemgmt operation. >> >> > > > > >> >> > > > > thank you if you can send some comment on this. >> >> > > > > >> >> > > >> >> >> >> -- >> >> Tom?? Mr?z >> >> No matter how far down the wrong road you've gone, turn back. >> >> Turkish proverb >> >> [You'll know whether the road is wrong if you carefully listen to your >> >> conscience.] >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sunil.Paramashivaiah at rbbn.com Fri Oct 8 08:59:54 2021 From: Sunil.Paramashivaiah at rbbn.com (Paramashivaiah, Sunil) Date: Fri, 8 Oct 2021 08:59:54 +0000 Subject: API to get BIGNUM member "top" in openssl 3.0 Message-ID: Hi Billy Brumley, I am trying to update the function eay_bn2v() in the racoon2 code. Please check the function in the below link https://android.googlesource.com/platform/external/ipsec-tools/+/051f86dfca525c160855397f7b6a4fb5ef8df2b5/src/racoon/crypto_openssl.c But I found one more source of racoon2 where they are using BN_num_bytes(bn) instead of bn->top * BN_BYTES in eay_bn2v() which I will try to use. Please find the same in the below link https://github.com/zoulasc/racoon2/blob/master/iked/crypto_openssl.c Thanks and Regards, Sunil Message: 1 Date: Fri, 8 Oct 2021 08:42:01 +0300 From: Billy Brumley To: "openssl-users at openssl.org" Subject: Re: API to get BIGNUM member "top" in openssl 3.0 Message-ID: Content-Type: text/plain; charset="UTF-8" > In our application we are accessing BIGNUM member top as > bn->top. Now we are trying > > to migrate to OPENSSL 3.0. I am unable to find API to access this member. > > Please let me know if there is any get API to get the ?top? member of BIGNUM. Since the structure is opaque, I can't imagine _really_ needing access to ->top since that is a BIGNUM-internal concept. Can you give a MWE for what you are trying to achieve? Cheers, BBB ------------------------------ Message: 2 Date: Fri, 8 Oct 2021 05:56:47 +0000 From: "Dr. Matthias St. Pierre" To: Billy Brumley , "openssl-users at openssl.org" Subject: RE: API to get BIGNUM member "top" in openssl 3.0 Message-ID: <3856680c276a4ddf80a5ab475c75b798 at ncp-e.com> Content-Type: text/plain; charset="utf-8" > Can you give a MWE for what you are trying to achieve? I guess that "minimal working example" is the correct choice from the gazillions of possible meanings of "MWE"? ? Regards, Matthias [1] https://clicktime.symantec.com/3Ay7qthuCEGV4fNJhsxkkbL6H2?u=https%3A%2F%2Fwww.acronymattic.com%2FMWE.html [2] https://clicktime.symantec.com/3Xu74FFughxyNMHvbwUk2Xv6H2?u=https%3A%2F%2Fwww.abbreviations.com%2FMWE Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. From Shivakumar.Poojari at rbbn.com Fri Oct 8 10:07:20 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Fri, 8 Oct 2021 10:07:20 +0000 Subject: [EXTERNAL] Re: Alternative for structure opaque X509 & X509_STORE_CTX In-Reply-To: References: Message-ID: HI Matt, For below error i tried your suggestion but return type are different, so facing issue in replacing, remaining suggestion are worked absolutely fine > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ok = ctx->verify_cb(0, ctx); X509_STORE_get_verify_cb() please suggest. Thanks, shivakumar ________________________________ From: Matt Caswell Sent: Tuesday, October 5, 2021 1:20 PM To: Shivakumar Poojari ; openssl-users at openssl.org Cc: Paramashivaiah, Sunil ; Kumar Mishra, Sanjeev ; Bhattacharjee, Debapriyo (c) Subject: [EXTERNAL] Re: Alternative for structure opaque X509 & X509_STORE_CTX On 05/10/2021 05:24, Shivakumar Poojari wrote: > :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > if (x->ocsp && x->ocsp->ocsp_url) Strangely there is no ocsp field in an x509_st even in 1.0.2 that I can see. > > :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > if(cert->sig_alg) > > :types.h:157:16: note: forward declaration of 'X509' {aka 'struct x509_st'} > typedef struct x509_st X509; > > error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > sigAlg = OBJ_obj2nid((cert)->sig_alg->algorithm); sig_alg is an X509_ALGOR structure which you get can using X509_get0_signature(). > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > x = ctx->cert; X509_STORE_CTX_get_current_cert() > ^~ > types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka > 'struct x509_store_ctx_st'} > typedef struct x509_store_ctx_st X509_STORE_CTX; > ^~~~~~~~~~~~~~~~~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ctx->current_cert = x; X509_STORE_CTX_set_current_cert() > ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ctx->current_issuer = NULL; > ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ctx->current_crl_score = 0; > ^~ > > types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka > 'struct x509_store_ctx_st'} > typedef struct x509_store_ctx_st X509_STORE_CTX; > ^~~~~~~~~~~~~~~~~ > > types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka > 'struct x509_store_ctx_st'} > typedef struct x509_store_ctx_st X509_STORE_CTX; > ^~~~~~~~~~~~~~~~~ > /sonus/p4/ws/spoojari/openssl3/marlin/SIPCM/sipCmOpenSSL.c:3268:8: > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ctx->current_reasons = 0; These fields can't be set individually. You have to reset the whole X509_STORE_CTX, e.g. via X509_STORE_CTX_init. > ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ctx->error = 0; X509_STORE_CTX_set_error() > ^~ > error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} > if (px->ocsp && (px->ocsp->ocsp_validate == > X509_OCSP_VALIDATE_DISABLED)) > ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > if (!ctx->ctx->ocsp_process_responder) > ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > store = ctx->ctx; > Use X509_STORE_CTX_get0_store() to get ctx->ctx. I can't find the field "ocsp_process_responder" ^~ > > error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct > x509_store_ctx_st'} > ok = ctx->verify_cb(0, ctx); X509_STORE_get_verify_cb() > ^~ > Getting above error in the code, Please provide the document that which > function i can use to resolve this errors. > > Thanks, > Shiva kumar > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Oct 8 15:11:35 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 8 Oct 2021 16:11:35 +0100 Subject: [EXTERNAL] Re: Alternative for structure opaque X509 & X509_STORE_CTX In-Reply-To: References: Message-ID: <652a0348-f34d-3a2d-841f-2073618d4706@openssl.org> On 08/10/2021 11:07, Shivakumar Poojari wrote: > HI?Matt, > > For below error i tried your suggestion but return type are different, > so facing issue in replacing, remaining suggestion are worked absolutely > fine >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >>? ? ? ? ? ?ok = ctx->verify_cb(0, ctx); > > X509_STORE_get_verify_cb() > I'm not sure what you mean by the return types are different X509_STORE_get_verify_cb, is declared as follows: X509_STORE_CTX_verify_cb X509_STORE_get_verify_cb(const X509_STORE *ctx); Where X509_STORE_CTX_verify_cb is declared as: typedef int (*X509_STORE_CTX_verify_cb)(int, X509_STORE_CTX *); So, this code is equivalent to your original code above: X509_STORE_CTX_verify_cb verify_cb; verify_cb = X509_STORE_get_verify_cb(ctx); ok = verify_cb(0, ctx); Matt > please suggest. > > Thanks, > shivakumar > ------------------------------------------------------------------------ > *From:* Matt Caswell > *Sent:* Tuesday, October 5, 2021 1:20 PM > *To:* Shivakumar Poojari ; > openssl-users at openssl.org > *Cc:* Paramashivaiah, Sunil ; Kumar > Mishra, Sanjeev ; Bhattacharjee, > Debapriyo (c) > *Subject:* [EXTERNAL] Re: Alternative for structure opaque X509 & > X509_STORE_CTX > > > On 05/10/2021 05:24, Shivakumar Poojari wrote: >> :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} >>? ? ? ?if (x->ocsp && x->ocsp->ocsp_url) > > Strangely there is no ocsp field in an x509_st even in 1.0.2 that I can see. > > >> >> :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} >>? ? ? ? ? ?if(cert->sig_alg) >> >> :types.h:157:16: note: forward declaration of 'X509' {aka 'struct x509_st'} >>? ?typedef struct x509_st X509; >> >> error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} >>? ? ? ? ? ? ? ?sigAlg = OBJ_obj2nid((cert)->sig_alg->algorithm); > > > sig_alg is an X509_ALGOR structure which you get can using > X509_get0_signature(). > >> >>? ?error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >>? ? ? ?x = ctx->cert; > > X509_STORE_CTX_get_current_cert() > >>? ? ? ? ? ? ? ^~ >> types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka >> 'struct x509_store_ctx_st'} >>? ?typedef struct x509_store_ctx_st X509_STORE_CTX; >>? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >>? ? ? ?ctx->current_cert = x; > > X509_STORE_CTX_set_current_cert() > >>? ? ? ? ? ^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >>? ? ? ?ctx->current_issuer = NULL; >>? ? ? ? ? ^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >>? ? ? ?ctx->current_crl_score = 0; >>? ? ? ? ? ^~ >> >> types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka >> 'struct x509_store_ctx_st'} >>? ?typedef struct x509_store_ctx_st X509_STORE_CTX; >>? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~ >> >> types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka >> 'struct x509_store_ctx_st'} >>? ?typedef struct x509_store_ctx_st X509_STORE_CTX; >>? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~ >> /sonus/p4/ws/spoojari/openssl3/marlin/SIPCM/sipCmOpenSSL.c:3268:8: >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >>? ? ? ?ctx->current_reasons = 0; > > > > These fields can't be set individually. You have to reset the whole > X509_STORE_CTX, e.g. via X509_STORE_CTX_init. > > >>? ? ? ? ? ^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >>? ? ? ?ctx->error = 0; > > > X509_STORE_CTX_set_error() > >>? ? ? ? ? ^~ >> error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} >>? ? ? ? ? ? ? ?if (px->ocsp && (px->ocsp->ocsp_validate == >> X509_OCSP_VALIDATE_DISABLED)) >>? ? ? ? ? ? ? ? ? ? ?^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >>? ? ? ? ? ?if (!ctx->ctx->ocsp_process_responder) >>? ? ? ? ? ? ? ? ? ?^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >>? ? ? ?store = ctx->ctx; >> > > Use X509_STORE_CTX_get0_store() to get ctx->ctx. I can't find the field > "ocsp_process_responder" > > > ? ? ? ? ? ? ? ? ? ^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >>? ? ? ? ? ?ok = ctx->verify_cb(0, ctx); > > X509_STORE_get_verify_cb() > > >>? ? ? ? ? ? ? ? ? ?^~ >> Getting above error in the code, Please provide the document that which >> function i can use to resolve this errors. >> >> Thanks, >> Shiva kumar >> >> Notice: This e-mail together with any attachments may contain >> information of Ribbon Communications Inc. and its Affiliates that is >> confidential and/or proprietary for the sole use of the intended >> recipient. Any review, disclosure, reliance or distribution by others or >> forwarding without express permission is strictly prohibited. If you are >> not the intended recipient, please notify the sender immediately and >> then delete all copies, including any attachments. > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. From piotr.lobacz at softgent.com Fri Oct 8 21:04:47 2021 From: piotr.lobacz at softgent.com (Piotr Lobacz) Date: Fri, 8 Oct 2021 21:04:47 +0000 Subject: ODP: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> <033cf963496decbca923af5d8ba4b1781ac1fd65.camel@openssl.org> Message-ID: Hi Antonio, I was discussing about this problem about half a year ago in here. The problem was itself in .net library but it concerned RSA_FLAG_EXT_PKEY in RSA_METHOD which is wrong. Yo can read it in here https://github.com/dotnet/runtime/issues/53345. The clue of my problem was that this flag was being set by the dotnet and engine was setting it in RSA_set_flags - which is the proper way. You need to verify how the engine sets this flag and read my issue maybe it will help you in solving yours. BR Piotr ________________________________ Od: openssl-users w imieniu u?ytkownika Antonio Santagiuliana Wys?ane: pi?tek, 8 pa?dziernika 2021 10:34 Do: Tomas Mraz DW: openssl-users at openssl.org Temat: Re: Store Mgmt and keys loading ( keyform ENG ) Could I ask you what is the best way to let the Openssl carry on in the case I can't pass the private key from my store manager load() function as key is offloaded in secure hw? I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the callback function from my Store Mgmt's load() where I get the uri ( the callback func is ossl_store_handle_load_result() ) I get error "could not read the private key". If instead I call the callback func , I don't know how to fill in its params , as I don't have the private key. What should I put in the params to let the rest of call chain ( I am on the dgst command ) not caring about private key but carry on with operation?or can I avoid calling the callback? Thank you On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana, > wrote: It is because of prototypes of methods.. On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, > wrote: Hello, just continuing on this.. I defined my store mgmt as : static const OSSL_ALGORITHM test_store[] = { { "handle", "provider=test", mystore_functions}, {NULL, NULL, NULL} }; echo "test" | LD_LIBRARY_PATH=. apps/openssl dgst --provider-path=./providers --provider=test --sign handle:1 -out messa.encrypted.bin Could not open file or uri for loading private key from handle:1 C0628C24787F0000:error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto/store/store_register.c:237:scheme=file C0628C24787F0000:error:1608010C:STORE routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No store loader found. For standard store loaders you need at least one of the default or base providers available. Did you forget to load them? Info: Global default library context, Scheme (file : 0), Properties () C0628C24787F0000:error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto/store/store_register.c:237:scheme=handle 1) It firstly looks for a provider for scheme file: and it doesn't find as I haven't set up any store mgmt for file: . 2) It looks like on second attempt it tries to look for handle: but it finds it not registered. What does this error mean ? Does it look for registered uri schemes online ? if that is the case how can this works instead : https://github.com/tpm2-software/tpm2-openssl ? They use handle: scheme as well. Does this mean it's a problem of the methods I registered for the store or is something related to the uri scheme I am using ? Sorry but I couldn't find more info on this in the sources/docs . thank you On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana > wrote: > > OK, thank you very much for your comments, that's clear. > > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, > wrote: >> >> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already >> modified to use OSSL_STORE API to load keys. So you do not need to >> specify keyform=ENGINE if your key is provided by a provider that >> supports the STORE functionality for some special URL scheme. You just >> specify the right URL with that scheme to reference the key in the >> provider. >> >> Of course third party applications need to be modified to call >> OSSL_STORE API in a similar way how the openssl application does it. >> >> Tomas >> >> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: >> > Thank you for your comment. >> > Am I wrong then in saying that dgst and possibly other apps are not >> > ready to be used with providers rather than engines in the case you >> > need keyform=ENGINE ? >> > >> > >> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, > wrote: >> > > You would have to implement a STORE provider that handles your >> > > special >> > > url scheme and then the keys would be referenced by the >> > > yourscheme://any-identifier-you-have. Of course the application >> > > (i.e., >> > > the openssl application which already does this) would have to use >> > > the >> > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER >> > > API >> > > or the d2i/PEM_read APIs. >> > > >> > > Tomas >> > > >> > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: >> > > > I checked the sources, I found that keyform cannot be set to >> > > > ENGINE >> > > > if engine is not specified in the command options, this is in the >> > > > function make_engine_url() called from load_key() when >> > > > format==FORMAT_ENGINE. >> > > > I am not specifying engine in the dgst command options as I am >> > > using >> > > > a provider. >> > > > I would like to achieve the same as FORMAT_ENGINE does, but with >> > > > provider. >> > > > >> > > > >> > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, >> > > > > wrote: >> > > > > Hello, >> > > > > I am doing my own provider starting from the default provider's >> > > > > code. >> > > > > I have now a question, I am seeing the STOREMGMT operation is >> > > > > required to interpret the URI of input private key, I would >> > > > > like >> > > > > that the string passed by the user for input key is not >> > > > > interpret >> > > > > as file to open but just my provider should save the string >> > > > > value >> > > > > to be used later .This is when invoking command options such >> > > > > as >> > > > > dgst sign -in "text" -keyform ENG. >> > > > > With engines' architecture this is possible by passing option - >> > > > > keyform ENG to dgst command. The string in that case is not >> > > > > interpreted as a file path and just passed through. >> > > > > There was engine_set_load_privkey_function that was getting >> > > > > this >> > > > > string. >> > > > > How can I achieve this now with the provider architecture ? If >> > > > > I >> > > > > pass -keyform ENG to dgst command together with --provider , it >> > > > > says "no engine specified to load private key" Should I use >> > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . >> > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I >> > > don't >> > > > > have a real private key info to load and use from a Filesystem. >> > > > > Is there anything to set in the KEYMGMT too ? I can see there >> > > > > is >> > > a >> > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key >> > > > > data in a key object should be considered. Not really sure if >> > > this >> > > > > is something I should set or not and how this keymgmt operation >> > > > > relates with storemgmt operation. >> > > > > >> > > > > thank you if you can send some comment on this. >> > > > > >> > > >> >> -- >> Tom?? Mr?z >> No matter how far down the wrong road you've gone, turn back. >> Turkish proverb >> [You'll know whether the road is wrong if you carefully listen to your >> conscience.] >> >> [https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png] Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND KRS: 0000674406, NIP: 9581679801, REGON: 367090912 www.softgent.com S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci. Jeste?my uczestnikiem Programu RZETELNA Firma Sprawd? nasz? rzetelno?? na https://www.rzetelnafirma.pl/F5IA32UW -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Oct 8 23:34:48 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 8 Oct 2021 19:34:48 -0400 Subject: [Mostly off-topic] Build RSA private key from (p,q,e) triple Message-ID: Every once in a while IIRC there are posts asking about how to create an RSA private key from the two prime factors (p and q) and exponent. Though there are surely simple examples in Python or Perl, I happened to write on in Haskell. Here it is for posterity (Main.hs and .cabal spec). Input is from stdin, with each of p, q and e in either decimal or 0x-prefixed hex on separate lines. 10 lines of boilerplate and 3 lines of code: ----------- Main.hs: module Main (main) where import qualified Data.ByteString as B import Crypto.Number.Basic (numBytes) import Crypto.PubKey.RSA (generateWith) import Data.ASN1.BinaryEncoding (DER(DER)) import Data.ASN1.Encoding (encodeASN1') import Data.ASN1.Types (toASN1) import Data.X509 (PrivKey(PrivKeyRSA)) main :: IO () main = do (p, q, e) <- (,,) <$> readLn <*> readLn <*> readLn mapM_ (B.putStr . toDER) $ generateWith (p,q) (numBytes (p*q)) e where toDER = encodeASN1' DER . flip toASN1 [] . PrivKeyRSA . snd ----------- pqe.cabal: cabal-version: 2.4 name: pqe version: 0.1.0.0 executable pqe main-is: Main.hs build-depends: base >= 4.14 && < 5 , asn1-encoding ^>= 0.9 , asn1-types ^>= 0.3 , bytestring >= 0.10 && < 0.12 , cryptonite ^>= 0.29 , x509 ^>= 1.7 ----------- The output is legacy RSA DER, but can be converted to PKCS8 PEM by piping it to "openssl pkey -inform DER" (optionally adding a passphrase, ...): If the program fails to read the (p, q, e) values it will exit with an error. If these fail to yield a valid key it will produce no output. Silly little example with (p, q, e) = (29, 23, 3): $ printf '%s\n%s\n%s\n' 29 23 3 | cabal run -v0 | openssl pkey -inform DER -text -----BEGIN PRIVATE KEY----- MDMCAQAwDQYJKoZIhvcNAQEBBQAEHzAdAgEAAgICmwIBAwICAZsCAR0CARcCARMC AQ8CARg= -----END PRIVATE KEY----- RSA Private-Key: (10 bit, 2 primes) modulus: 667 (0x29b) publicExponent: 3 (0x3) privateExponent: 411 (0x19b) prime1: 29 (0x1d) prime2: 23 (0x17) exponent1: 19 (0x13) exponent2: 15 (0xf) coefficient: 24 (0x18) More realistic example with a throw-away 2048-bit RSA key: $ cabal run -v0 < 0xfb9e9c8a90615c9edd4870b2eb434a76abcf8ffe22d0764fdf9c921523b561b25edd2ebc547836ab2e40ba7229e2f023dde7f2209c0d8ba548d442a7e9ee415f97714a1f6cdd53aa6e67b2d020287c4b2fe730355e04fb25f93b078bf41a7af8e6700c4cf2e2407720e19f90464d8e9cb4d70d960c23309b3228b5510e550833 > 0xe779cd8cc5a7d3ae41cfe4869598832aeec3e26b0919743486f9e5d0cf1e00826a6ffe865d347e35b0c55cfcef32515b6850d552be53b5af335c3e0a8062a5d4e063b33071365f3faac29e44990f83f2994bb93cf45a0c09a4fef13e441128ebe9c36ef2dc32dddffc99ed7d1ad7bc0232c1692ff3ee466c6bcb612074d54187 > 0x10001 > EOF -----BEGIN PRIVATE KEY----- MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDjg9dBZiSs+s4w JZgYVNknm6TW4vh8lONdEOe6lquTYDciA53K00dededDmjwvQYMHbsoA6TyC/5O4 r8T21GaXwdQHHOsMou9JcyU+5Sun350I2lh7sDeJ0Ipz/nn3RwitXBHeWMLz1MLD Arutm0Wc1ZFC0ri2sxXTXsoYYc4mqMCBp0C8sPkQCAkheCsOBkWHaYK6vlsOXK/V O1LMaxqawYZamfPQ7Nznh3rVjVY2v/zlEtHqtNbzjMu6cJrLKgzYzhfxWMO/aNA/ QhjZoUjSNFTP5VwhpyP7EFQlrMQFLb4vumboj5G66jiHWk/SeDn5LxhLyFbnijSe ADkUW0XlAgMBAAECggEBALnNBLCrCw6dMF/Pg9tzB3i6Oi8nYsjTCq8JTEVsIKiV rdDAZU+rpaA152yk+7uX47rhNmTyFPHiaLAuE0uEgFg0+cPpUOeb9JDmUSeBHlrV WjhNoG86pNCOl1NNIivYPfTduNX9ZRCd04RQqhaINJx1KVEKJ8FElXFt+ttYnHOi WDVGtpXYNjM+6s/R6UpkSTL0SpVjY7RjQMXZ8P3uUrAru/4UQba0ZcZIbHXSQO5J MCWa05pIOGuTs0C/2nUuO+lN5fqz6Cv8G+YlQjp54MUcjK3XisP/vx9GC4uvt3XT ik8y/+plvvBk1nwO8ehJ01bUzgokWNkePI58lfczqu0CgYEA+56cipBhXJ7dSHCy 60NKdqvPj/4i0HZP35ySFSO1YbJe3S68VHg2qy5AunIp4vAj3efyIJwNi6VI1EKn 6e5BX5dxSh9s3VOqbmey0CAofEsv5zA1XgT7Jfk7B4v0Gnr45nAMTPLiQHcg4Z+Q Rk2OnLTXDZYMIzCbMii1UQ5VCDMCgYEA53nNjMWn065Bz+SGlZiDKu7D4msJGXQ0 hvnl0M8eAIJqb/6GXTR+NbDFXPzvMlFbaFDVUr5Tta8zXD4KgGKl1OBjszBxNl8/ qsKeRJkPg/KZS7k89FoMCaT+8T5EESjr6cNu8twy3d/8me19Gte8AjLBaS/z7kZs a8thIHTVQYcCgYEAw1apdLENxNfYNmq3nAkLgAF2C/VhlbCj5ZcpmZu1LnlJSDEG KBWDa3Vm7te+SN3hGl79C+/aXDUeyxpMPUGoIsvxOXgYDeLsBvYeTZEJnSTJtZMp eyomx54rA3rVMNGS9WK7SemtWBqjvkUfvlRriKCj63o3RgJwGYqc6KZVwR0CgYEA uNfNSrKz+BfZOhg1WNR3Oht8lRwAIjFnmLmJyZr7TFDYiiJoTZmTh3Bnyn+4yyeo pL6X+wE9e4Iys2BfpnIgFsQxGXB/l3msL8JF/GV1vFpIC+4aPM6DelgltaORW1qg OQX1XT516DPrVUgOdRb9bYv2YvcGBap6/gFkyDRD75UCgYAkruxwtnikj5hKlaSJ /OIXvjj3VmbPpJtSFbvadTCTzBxWCWjaBQHf0nKsbNRa/9V60y44L0EVnC40Udj6 r6LxLw66+GHJQPfhW5bnFIpUksIDC8fF9gUyc+C0AI3OJR+jrmlXNAllqoNIEsYd mkdZ2BxLEY0/fmBftSO3d/dC+A== -----END PRIVATE KEY----- -- Viktor. From Shivakumar.Poojari at rbbn.com Mon Oct 11 05:41:03 2021 From: Shivakumar.Poojari at rbbn.com (Shivakumar Poojari) Date: Mon, 11 Oct 2021 05:41:03 +0000 Subject: [EXTERNAL] Re: Alternative for structure opaque X509 & X509_STORE_CTX In-Reply-To: <652a0348-f34d-3a2d-841f-2073618d4706@openssl.org> References: <652a0348-f34d-3a2d-841f-2073618d4706@openssl.org> Message-ID: Hi Matt The return type of ctx->verify_cb(0, ctx) is int and the return type of X509_STORE_get_verify_cb() is X509_STORE_CTX_verify_cb in this case how do i match/replace int ok=1; ok = ctx->verify_cb(0, ctx); X509_STORE_CTX_verify_cb verify_cb; verify_cb = X509_STORE_get_verify_cb(ctx); Thanks Shiva kumar ________________________________ From: Matt Caswell Sent: Friday, October 8, 2021 8:41 PM To: Shivakumar Poojari ; openssl-users at openssl.org Cc: Paramashivaiah, Sunil ; Kumar Mishra, Sanjeev ; Bhattacharjee, Debapriyo (c) Subject: Re: [EXTERNAL] Re: Alternative for structure opaque X509 & X509_STORE_CTX On 08/10/2021 11:07, Shivakumar Poojari wrote: > HI Matt, > > For below error i tried your suggestion but return type are different, > so facing issue in replacing, remaining suggestion are worked absolutely > fine >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >> ok = ctx->verify_cb(0, ctx); > > X509_STORE_get_verify_cb() > I'm not sure what you mean by the return types are different X509_STORE_get_verify_cb, is declared as follows: X509_STORE_CTX_verify_cb X509_STORE_get_verify_cb(const X509_STORE *ctx); Where X509_STORE_CTX_verify_cb is declared as: typedef int (*X509_STORE_CTX_verify_cb)(int, X509_STORE_CTX *); So, this code is equivalent to your original code above: X509_STORE_CTX_verify_cb verify_cb; verify_cb = X509_STORE_get_verify_cb(ctx); ok = verify_cb(0, ctx); Matt > please suggest. > > Thanks, > shivakumar > ------------------------------------------------------------------------ > *From:* Matt Caswell > *Sent:* Tuesday, October 5, 2021 1:20 PM > *To:* Shivakumar Poojari ; > openssl-users at openssl.org > *Cc:* Paramashivaiah, Sunil ; Kumar > Mishra, Sanjeev ; Bhattacharjee, > Debapriyo (c) > *Subject:* [EXTERNAL] Re: Alternative for structure opaque X509 & > X509_STORE_CTX > > > On 05/10/2021 05:24, Shivakumar Poojari wrote: >> :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} >> if (x->ocsp && x->ocsp->ocsp_url) > > Strangely there is no ocsp field in an x509_st even in 1.0.2 that I can see. > > >> >> :error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} >> if(cert->sig_alg) >> >> :types.h:157:16: note: forward declaration of 'X509' {aka 'struct x509_st'} >> typedef struct x509_st X509; >> >> error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} >> sigAlg = OBJ_obj2nid((cert)->sig_alg->algorithm); > > > sig_alg is an X509_ALGOR structure which you get can using > X509_get0_signature(). > >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >> x = ctx->cert; > > X509_STORE_CTX_get_current_cert() > >> ^~ >> types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka >> 'struct x509_store_ctx_st'} >> typedef struct x509_store_ctx_st X509_STORE_CTX; >> ^~~~~~~~~~~~~~~~~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >> ctx->current_cert = x; > > X509_STORE_CTX_set_current_cert() > >> ^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >> ctx->current_issuer = NULL; >> ^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >> ctx->current_crl_score = 0; >> ^~ >> >> types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka >> 'struct x509_store_ctx_st'} >> typedef struct x509_store_ctx_st X509_STORE_CTX; >> ^~~~~~~~~~~~~~~~~ >> >> types.h:165:16: note: forward declaration of 'X509_STORE_CTX' {aka >> 'struct x509_store_ctx_st'} >> typedef struct x509_store_ctx_st X509_STORE_CTX; >> ^~~~~~~~~~~~~~~~~ >> /sonus/p4/ws/spoojari/openssl3/marlin/SIPCM/sipCmOpenSSL.c:3268:8: >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >> ctx->current_reasons = 0; > > > > These fields can't be set individually. You have to reset the whole > X509_STORE_CTX, e.g. via X509_STORE_CTX_init. > > >> ^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >> ctx->error = 0; > > > X509_STORE_CTX_set_error() > >> ^~ >> error: invalid use of incomplete type 'X509' {aka 'struct x509_st'} >> if (px->ocsp && (px->ocsp->ocsp_validate == >> X509_OCSP_VALIDATE_DISABLED)) >> ^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >> if (!ctx->ctx->ocsp_process_responder) >> ^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >> store = ctx->ctx; >> > > Use X509_STORE_CTX_get0_store() to get ctx->ctx. I can't find the field > "ocsp_process_responder" > > > ^~ >> >> error: invalid use of incomplete type 'X509_STORE_CTX' {aka 'struct >> x509_store_ctx_st'} >> ok = ctx->verify_cb(0, ctx); > > X509_STORE_get_verify_cb() > > >> ^~ >> Getting above error in the code, Please provide the document that which >> function i can use to resolve this errors. >> >> Thanks, >> Shiva kumar >> >> Notice: This e-mail together with any attachments may contain >> information of Ribbon Communications Inc. and its Affiliates that is >> confidential and/or proprietary for the sole use of the intended >> recipient. Any review, disclosure, reliance or distribution by others or >> forwarding without express permission is strictly prohibited. If you are >> not the intended recipient, please notify the sender immediately and >> then delete all copies, including any attachments. > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From santantonioswap at gmail.com Tue Oct 12 08:22:34 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Tue, 12 Oct 2021 09:22:34 +0100 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> <033cf963496decbca923af5d8ba4b1781ac1fd65.camel@openssl.org> Message-ID: Thank you for the suggestion. I am using providers though, not engine, and I can't see the higher level checking this RSA flags before it has detected a valid key is passed back from the store manager to ossl_store_handle_load_result() ( the callback passed to the store mgmt load() method). If I don't call the callback ossl_store_handle_load_result the higher level after the store mgmt load() complains no private key can be read. If I pass back an RSA key generated on the fly in the store mgmt load() then the ossl_store_handle_load_result() is fine using the RSA key mgmt load finds error in checking RSA flags , I think these flags are not set but I don't know how to set them in the fictitious private key I generated on the fly in the store mgmt load() with EVP_PKEY *pkey = NULL; pkey = EVP_RSA_gen(2048); This produces a valid pkey without errors but I think the rsa fields are not filled in.How can I add them to pkey ? I think I should register a different keymgmt on my provider but I am not sure what it should do in my case. So , for now, the RSA keymgmt is called and in its load() function ( rsa_load() ) at some point it wants to check RSA_check_flags() and there it stops as the rsa struct fileds referenced are not filled in. On Fri, 8 Oct 2021, 22:04 Piotr Lobacz, wrote: > Hi Antonio, > I was discussing about this problem about half a year ago in here. The > problem was itself in .net library but it concerned RSA_FLAG_EXT_PKEY in > RSA_METHOD which is wrong. Yo can read it in here > https://github.com/dotnet/runtime/issues/53345. The clue of my problem > was that this flag was being set by the dotnet and engine was setting it in > RSA_set_flags - which is the proper way. You need to verify how the engine > sets this flag and read my issue maybe it will help you in solving yours. > > BR > Piotr > ------------------------------ > *Od:* openssl-users w imieniu > u?ytkownika Antonio Santagiuliana > *Wys?ane:* pi?tek, 8 pa?dziernika 2021 10:34 > *Do:* Tomas Mraz > *DW:* openssl-users at openssl.org > *Temat:* Re: Store Mgmt and keys loading ( keyform ENG ) > > Could I ask you what is the best way to let the Openssl carry on in the > case I can't pass the private key from my store manager load() function as > key is offloaded in secure hw? > I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the > callback function from my Store Mgmt's load() where I get the uri ( the > callback func is ossl_store_handle_load_result() ) I get error "could not > read the private key". > If instead I call the callback func , I don't know how to fill in its > params , as I don't have the private key. What should I put in the params > to let the rest of call chain ( I am on the dgst command ) not caring about > private key but carry on with operation?or can I avoid calling the callback? > Thank you > > On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana, < > santantonioswap at gmail.com> wrote: > > It is because of prototypes of methods.. > > On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, < > santantonioswap at gmail.com> wrote: > > Hello, > just continuing on this.. > I defined my store mgmt as : > static const OSSL_ALGORITHM test_store[] = { > { "handle", "provider=test", mystore_functions}, > {NULL, NULL, NULL} > }; > > echo "test" | LD_LIBRARY_PATH=. apps/openssl dgst > --provider-path=./providers --provider=test --sign handle:1 -out > messa.encrypted.bin > > Could not open file or uri for loading private key from handle:1 > > C0628C24787F0000:error:16000069:STORE > routines:ossl_store_get0_loader_int:unregistered > scheme:crypto/store/store_register.c:237:scheme=file > > C0628C24787F0000:error:1608010C:STORE > routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No > store loader found. For standard store loaders you need at least one > of the default or base providers available. Did you forget to load > them? Info: Global default library context, Scheme (file : 0), > Properties () > > C0628C24787F0000:error:16000069:STORE > routines:ossl_store_get0_loader_int:unregistered > scheme:crypto/store/store_register.c:237:scheme=handle > > 1) It firstly looks for a provider for scheme file: and it doesn't > find as I haven't set up any store mgmt for file: . > > 2) It looks like on second attempt it tries to look for handle: but it > finds it not registered. What does this error mean ? Does it look for > registered uri schemes online ? if that is the case how can this works > instead : https://github.com/tpm2-software/tpm2-openssl ? They use > handle: scheme as well. > > Does this mean it's a problem of the methods I registered for the > store or is something related to the uri scheme I am using ? > Sorry but I couldn't find more info on this in the sources/docs . > > > thank you > > > > On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana > wrote: > > > > OK, thank you very much for your comments, that's clear. > > > > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote: > >> > >> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already > >> modified to use OSSL_STORE API to load keys. So you do not need to > >> specify keyform=ENGINE if your key is provided by a provider that > >> supports the STORE functionality for some special URL scheme. You just > >> specify the right URL with that scheme to reference the key in the > >> provider. > >> > >> Of course third party applications need to be modified to call > >> OSSL_STORE API in a similar way how the openssl application does it. > >> > >> Tomas > >> > >> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: > >> > Thank you for your comment. > >> > Am I wrong then in saying that dgst and possibly other apps are not > >> > ready to be used with providers rather than engines in the case you > >> > need keyform=ENGINE ? > >> > > >> > > >> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: > >> > > You would have to implement a STORE provider that handles your > >> > > special > >> > > url scheme and then the keys would be referenced by the > >> > > yourscheme://any-identifier-you-have. Of course the application > >> > > (i.e., > >> > > the openssl application which already does this) would have to use > >> > > the > >> > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER > >> > > API > >> > > or the d2i/PEM_read APIs. > >> > > > >> > > Tomas > >> > > > >> > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: > >> > > > I checked the sources, I found that keyform cannot be set to > >> > > > ENGINE > >> > > > if engine is not specified in the command options, this is in the > >> > > > function make_engine_url() called from load_key() when > >> > > > format==FORMAT_ENGINE. > >> > > > I am not specifying engine in the dgst command options as I am > >> > > using > >> > > > a provider. > >> > > > I would like to achieve the same as FORMAT_ENGINE does, but with > >> > > > provider. > >> > > > > >> > > > > >> > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, > >> > > > wrote: > >> > > > > Hello, > >> > > > > I am doing my own provider starting from the default provider's > >> > > > > code. > >> > > > > I have now a question, I am seeing the STOREMGMT operation is > >> > > > > required to interpret the URI of input private key, I would > >> > > > > like > >> > > > > that the string passed by the user for input key is not > >> > > > > interpret > >> > > > > as file to open but just my provider should save the string > >> > > > > value > >> > > > > to be used later .This is when invoking command options such > >> > > > > as > >> > > > > dgst sign -in "text" -keyform ENG. > >> > > > > With engines' architecture this is possible by passing option - > >> > > > > keyform ENG to dgst command. The string in that case is not > >> > > > > interpreted as a file path and just passed through. > >> > > > > There was engine_set_load_privkey_function that was getting > >> > > > > this > >> > > > > string. > >> > > > > How can I achieve this now with the provider architecture ? If > >> > > > > I > >> > > > > pass -keyform ENG to dgst command together with --provider , it > >> > > > > says "no engine specified to load private key" Should I use > >> > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . > >> > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I > >> > > don't > >> > > > > have a real private key info to load and use from a Filesystem. > >> > > > > Is there anything to set in the KEYMGMT too ? I can see there > >> > > > > is > >> > > a > >> > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key > >> > > > > data in a key object should be considered. Not really sure if > >> > > this > >> > > > > is something I should set or not and how this keymgmt operation > >> > > > > relates with storemgmt operation. > >> > > > > > >> > > > > thank you if you can send some comment on this. > >> > > > > > >> > > > >> > >> -- > >> Tom?? Mr?z > >> No matter how far down the wrong road you've gone, turn back. > >> Turkish proverb > >> [You'll know whether the road is wrong if you carefully listen to your > >> conscience.] > >> > >> > > > > *Softgent Sp. z o.o.*, Budowlanych 31d, 80-298 Gdansk, POLAND > > KRS: 0000674406, NIP: 9581679801, REGON: 367090912 > www.softgent.com > > S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego > Rejestru S?dowego > > KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci. > > Jeste?my uczestnikiem Programu > *RZETELNA* *Firma * > Sprawd? nasz? rzetelno?? na > https://www.rzetelnafirma.pl/F5IA32UW > -------------- next part -------------- An HTML attachment was scrubbed... URL: From santantonioswap at gmail.com Tue Oct 12 08:50:40 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Tue, 12 Oct 2021 09:50:40 +0100 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> <033cf963496decbca923af5d8ba4b1781ac1fd65.camel@openssl.org> Message-ID: in general, I think that despite what I read in previous replies, with the operation: dgst --provider=myprovider -sign handle:1 is not possible to fully reproduce what was possible with engines : dgst -keyform ENG sign -in 1 -engine=myengine. In the case of provider the store manager's caller sets ossl_store_handle_load_result as fixed callback method when calling the load of store mgmt. If that callback is not called , it will complain as no private key is possible to read. On Tue, Oct 12, 2021 at 9:22 AM Antonio Santagiuliana < santantonioswap at gmail.com> wrote: > Thank you for the suggestion. > I am using providers though, not engine, and I can't see the higher level > checking this RSA flags before it has detected a valid key is passed back > from the store manager to ossl_store_handle_load_result() ( the callback > passed to the store mgmt load() method). > If I don't call the callback ossl_store_handle_load_result the higher > level after the store mgmt load() complains no private key can be read. > If I pass back an RSA key generated on the fly in the store mgmt load() > then the ossl_store_handle_load_result() is fine using the RSA key mgmt > load finds error in checking RSA flags , I think these flags are not set > but I don't know how to set them in the fictitious private key I generated > on the fly in the store mgmt load() with > EVP_PKEY *pkey = NULL; > pkey = EVP_RSA_gen(2048); > This produces a valid pkey without errors but I think the rsa fields are > not filled in.How can I add them to pkey ? > I think I should register a different keymgmt on my provider but I am not > sure what it should do in my case. > So , for now, the RSA keymgmt is called and in its load() function > ( rsa_load() ) at some point it wants to check RSA_check_flags() and there > it stops as the rsa struct fileds referenced are not filled in. > > > > On Fri, 8 Oct 2021, 22:04 Piotr Lobacz, wrote: > >> Hi Antonio, >> I was discussing about this problem about half a year ago in here. The >> problem was itself in .net library but it concerned RSA_FLAG_EXT_PKEY in >> RSA_METHOD which is wrong. Yo can read it in here >> https://github.com/dotnet/runtime/issues/53345. The clue of my problem >> was that this flag was being set by the dotnet and engine was setting it in >> RSA_set_flags - which is the proper way. You need to verify how the engine >> sets this flag and read my issue maybe it will help you in solving yours. >> >> BR >> Piotr >> ------------------------------ >> *Od:* openssl-users w imieniu >> u?ytkownika Antonio Santagiuliana >> *Wys?ane:* pi?tek, 8 pa?dziernika 2021 10:34 >> *Do:* Tomas Mraz >> *DW:* openssl-users at openssl.org >> *Temat:* Re: Store Mgmt and keys loading ( keyform ENG ) >> >> Could I ask you what is the best way to let the Openssl carry on in the >> case I can't pass the private key from my store manager load() function as >> key is offloaded in secure hw? >> I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the >> callback function from my Store Mgmt's load() where I get the uri ( the >> callback func is ossl_store_handle_load_result() ) I get error "could not >> read the private key". >> If instead I call the callback func , I don't know how to fill in its >> params , as I don't have the private key. What should I put in the params >> to let the rest of call chain ( I am on the dgst command ) not caring about >> private key but carry on with operation?or can I avoid calling the callback? >> Thank you >> >> On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana, < >> santantonioswap at gmail.com> wrote: >> >> It is because of prototypes of methods.. >> >> On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, < >> santantonioswap at gmail.com> wrote: >> >> Hello, >> just continuing on this.. >> I defined my store mgmt as : >> static const OSSL_ALGORITHM test_store[] = { >> { "handle", "provider=test", mystore_functions}, >> {NULL, NULL, NULL} >> }; >> >> echo "test" | LD_LIBRARY_PATH=. apps/openssl dgst >> --provider-path=./providers --provider=test --sign handle:1 -out >> messa.encrypted.bin >> >> Could not open file or uri for loading private key from handle:1 >> >> C0628C24787F0000:error:16000069:STORE >> routines:ossl_store_get0_loader_int:unregistered >> scheme:crypto/store/store_register.c:237:scheme=file >> >> C0628C24787F0000:error:1608010C:STORE >> routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No >> store loader found. For standard store loaders you need at least one >> of the default or base providers available. Did you forget to load >> them? Info: Global default library context, Scheme (file : 0), >> Properties () >> >> C0628C24787F0000:error:16000069:STORE >> routines:ossl_store_get0_loader_int:unregistered >> scheme:crypto/store/store_register.c:237:scheme=handle >> >> 1) It firstly looks for a provider for scheme file: and it doesn't >> find as I haven't set up any store mgmt for file: . >> >> 2) It looks like on second attempt it tries to look for handle: but it >> finds it not registered. What does this error mean ? Does it look for >> registered uri schemes online ? if that is the case how can this works >> instead : https://github.com/tpm2-software/tpm2-openssl ? They use >> handle: scheme as well. >> >> Does this mean it's a problem of the methods I registered for the >> store or is something related to the uri scheme I am using ? >> Sorry but I couldn't find more info on this in the sources/docs . >> >> >> thank you >> >> >> >> On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana >> wrote: >> > >> > OK, thank you very much for your comments, that's clear. >> > >> > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote: >> >> >> >> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already >> >> modified to use OSSL_STORE API to load keys. So you do not need to >> >> specify keyform=ENGINE if your key is provided by a provider that >> >> supports the STORE functionality for some special URL scheme. You just >> >> specify the right URL with that scheme to reference the key in the >> >> provider. >> >> >> >> Of course third party applications need to be modified to call >> >> OSSL_STORE API in a similar way how the openssl application does it. >> >> >> >> Tomas >> >> >> >> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: >> >> > Thank you for your comment. >> >> > Am I wrong then in saying that dgst and possibly other apps are not >> >> > ready to be used with providers rather than engines in the case you >> >> > need keyform=ENGINE ? >> >> > >> >> > >> >> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: >> >> > > You would have to implement a STORE provider that handles your >> >> > > special >> >> > > url scheme and then the keys would be referenced by the >> >> > > yourscheme://any-identifier-you-have. Of course the application >> >> > > (i.e., >> >> > > the openssl application which already does this) would have to use >> >> > > the >> >> > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER >> >> > > API >> >> > > or the d2i/PEM_read APIs. >> >> > > >> >> > > Tomas >> >> > > >> >> > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: >> >> > > > I checked the sources, I found that keyform cannot be set to >> >> > > > ENGINE >> >> > > > if engine is not specified in the command options, this is in the >> >> > > > function make_engine_url() called from load_key() when >> >> > > > format==FORMAT_ENGINE. >> >> > > > I am not specifying engine in the dgst command options as I am >> >> > > using >> >> > > > a provider. >> >> > > > I would like to achieve the same as FORMAT_ENGINE does, but with >> >> > > > provider. >> >> > > > >> >> > > > >> >> > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, >> >> > > > wrote: >> >> > > > > Hello, >> >> > > > > I am doing my own provider starting from the default provider's >> >> > > > > code. >> >> > > > > I have now a question, I am seeing the STOREMGMT operation is >> >> > > > > required to interpret the URI of input private key, I would >> >> > > > > like >> >> > > > > that the string passed by the user for input key is not >> >> > > > > interpret >> >> > > > > as file to open but just my provider should save the string >> >> > > > > value >> >> > > > > to be used later .This is when invoking command options such >> >> > > > > as >> >> > > > > dgst sign -in "text" -keyform ENG. >> >> > > > > With engines' architecture this is possible by passing option - >> >> > > > > keyform ENG to dgst command. The string in that case is not >> >> > > > > interpreted as a file path and just passed through. >> >> > > > > There was engine_set_load_privkey_function that was getting >> >> > > > > this >> >> > > > > string. >> >> > > > > How can I achieve this now with the provider architecture ? If >> >> > > > > I >> >> > > > > pass -keyform ENG to dgst command together with --provider , it >> >> > > > > says "no engine specified to load private key" Should I use >> >> > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . >> >> > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I >> >> > > don't >> >> > > > > have a real private key info to load and use from a Filesystem. >> >> > > > > Is there anything to set in the KEYMGMT too ? I can see there >> >> > > > > is >> >> > > a >> >> > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key >> >> > > > > data in a key object should be considered. Not really sure if >> >> > > this >> >> > > > > is something I should set or not and how this keymgmt operation >> >> > > > > relates with storemgmt operation. >> >> > > > > >> >> > > > > thank you if you can send some comment on this. >> >> > > > > >> >> > > >> >> >> >> -- >> >> Tom?? Mr?z >> >> No matter how far down the wrong road you've gone, turn back. >> >> Turkish proverb >> >> [You'll know whether the road is wrong if you carefully listen to your >> >> conscience.] >> >> >> >> >> >> >> >> *Softgent Sp. z o.o.*, Budowlanych 31d, 80-298 Gdansk, POLAND >> >> KRS: 0000674406, NIP: 9581679801, REGON: 367090912 >> www.softgent.com >> >> S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego >> Rejestru S?dowego >> >> KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci. >> >> Jeste?my uczestnikiem Programu >> *RZETELNA* *Firma * >> Sprawd? nasz? rzetelno?? na >> https://www.rzetelnafirma.pl/F5IA32UW >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From piotr.lobacz at softgent.com Tue Oct 12 12:35:28 2021 From: piotr.lobacz at softgent.com (Piotr Lobacz) Date: Tue, 12 Oct 2021 12:35:28 +0000 Subject: ODP: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> <033cf963496decbca923af5d8ba4b1781ac1fd65.camel@openssl.org> Message-ID: I'm sorry i cannot help you with providers. All i can tell you, is that in my case libpkcs11 was not setting using RSA_meth_set_flags but RSA_set_flags and in dotnet openssl implementation, the check was being made on the method. I was thinking that our issues may be related. BR Piotr ________________________________ Od: Antonio Santagiuliana Wys?ane: wtorek, 12 pa?dziernika 2021 10:50 Do: Piotr Lobacz ; openssl-users at openssl.org Temat: Re: Store Mgmt and keys loading ( keyform ENG ) in general, I think that despite what I read in previous replies, with the operation: dgst --provider=myprovider -sign handle:1 is not possible to fully reproduce what was possible with engines : dgst -keyform ENG sign -in 1 -engine=myengine. In the case of provider the store manager's caller sets ossl_store_handle_load_result as fixed callback method when calling the load of store mgmt. If that callback is not called , it will complain as no private key is possible to read. On Tue, Oct 12, 2021 at 9:22 AM Antonio Santagiuliana > wrote: Thank you for the suggestion. I am using providers though, not engine, and I can't see the higher level checking this RSA flags before it has detected a valid key is passed back from the store manager to ossl_store_handle_load_result() ( the callback passed to the store mgmt load() method). If I don't call the callback ossl_store_handle_load_result the higher level after the store mgmt load() complains no private key can be read. If I pass back an RSA key generated on the fly in the store mgmt load() then the ossl_store_handle_load_result() is fine using the RSA key mgmt load finds error in checking RSA flags , I think these flags are not set but I don't know how to set them in the fictitious private key I generated on the fly in the store mgmt load() with EVP_PKEY *pkey = NULL; pkey = EVP_RSA_gen(2048); This produces a valid pkey without errors but I think the rsa fields are not filled in.How can I add them to pkey ? I think I should register a different keymgmt on my provider but I am not sure what it should do in my case. So , for now, the RSA keymgmt is called and in its load() function ( rsa_load() ) at some point it wants to check RSA_check_flags() and there it stops as the rsa struct fileds referenced are not filled in. On Fri, 8 Oct 2021, 22:04 Piotr Lobacz, > wrote: Hi Antonio, I was discussing about this problem about half a year ago in here. The problem was itself in .net library but it concerned RSA_FLAG_EXT_PKEY in RSA_METHOD which is wrong. Yo can read it in here https://github.com/dotnet/runtime/issues/53345. The clue of my problem was that this flag was being set by the dotnet and engine was setting it in RSA_set_flags - which is the proper way. You need to verify how the engine sets this flag and read my issue maybe it will help you in solving yours. BR Piotr ________________________________ Od: openssl-users > w imieniu u?ytkownika Antonio Santagiuliana > Wys?ane: pi?tek, 8 pa?dziernika 2021 10:34 Do: Tomas Mraz > DW: openssl-users at openssl.org > Temat: Re: Store Mgmt and keys loading ( keyform ENG ) Could I ask you what is the best way to let the Openssl carry on in the case I can't pass the private key from my store manager load() function as key is offloaded in secure hw? I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the callback function from my Store Mgmt's load() where I get the uri ( the callback func is ossl_store_handle_load_result() ) I get error "could not read the private key". If instead I call the callback func , I don't know how to fill in its params , as I don't have the private key. What should I put in the params to let the rest of call chain ( I am on the dgst command ) not caring about private key but carry on with operation?or can I avoid calling the callback? Thank you On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana, > wrote: It is because of prototypes of methods.. On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, > wrote: Hello, just continuing on this.. I defined my store mgmt as : static const OSSL_ALGORITHM test_store[] = { { "handle", "provider=test", mystore_functions}, {NULL, NULL, NULL} }; echo "test" | LD_LIBRARY_PATH=. apps/openssl dgst --provider-path=./providers --provider=test --sign handle:1 -out messa.encrypted.bin Could not open file or uri for loading private key from handle:1 C0628C24787F0000:error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto/store/store_register.c:237:scheme=file C0628C24787F0000:error:1608010C:STORE routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No store loader found. For standard store loaders you need at least one of the default or base providers available. Did you forget to load them? Info: Global default library context, Scheme (file : 0), Properties () C0628C24787F0000:error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto/store/store_register.c:237:scheme=handle 1) It firstly looks for a provider for scheme file: and it doesn't find as I haven't set up any store mgmt for file: . 2) It looks like on second attempt it tries to look for handle: but it finds it not registered. What does this error mean ? Does it look for registered uri schemes online ? if that is the case how can this works instead : https://github.com/tpm2-software/tpm2-openssl ? They use handle: scheme as well. Does this mean it's a problem of the methods I registered for the store or is something related to the uri scheme I am using ? Sorry but I couldn't find more info on this in the sources/docs . thank you On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana > wrote: > > OK, thank you very much for your comments, that's clear. > > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, > wrote: >> >> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already >> modified to use OSSL_STORE API to load keys. So you do not need to >> specify keyform=ENGINE if your key is provided by a provider that >> supports the STORE functionality for some special URL scheme. You just >> specify the right URL with that scheme to reference the key in the >> provider. >> >> Of course third party applications need to be modified to call >> OSSL_STORE API in a similar way how the openssl application does it. >> >> Tomas >> >> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: >> > Thank you for your comment. >> > Am I wrong then in saying that dgst and possibly other apps are not >> > ready to be used with providers rather than engines in the case you >> > need keyform=ENGINE ? >> > >> > >> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, > wrote: >> > > You would have to implement a STORE provider that handles your >> > > special >> > > url scheme and then the keys would be referenced by the >> > > yourscheme://any-identifier-you-have. Of course the application >> > > (i.e., >> > > the openssl application which already does this) would have to use >> > > the >> > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER >> > > API >> > > or the d2i/PEM_read APIs. >> > > >> > > Tomas >> > > >> > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: >> > > > I checked the sources, I found that keyform cannot be set to >> > > > ENGINE >> > > > if engine is not specified in the command options, this is in the >> > > > function make_engine_url() called from load_key() when >> > > > format==FORMAT_ENGINE. >> > > > I am not specifying engine in the dgst command options as I am >> > > using >> > > > a provider. >> > > > I would like to achieve the same as FORMAT_ENGINE does, but with >> > > > provider. >> > > > >> > > > >> > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, >> > > > > wrote: >> > > > > Hello, >> > > > > I am doing my own provider starting from the default provider's >> > > > > code. >> > > > > I have now a question, I am seeing the STOREMGMT operation is >> > > > > required to interpret the URI of input private key, I would >> > > > > like >> > > > > that the string passed by the user for input key is not >> > > > > interpret >> > > > > as file to open but just my provider should save the string >> > > > > value >> > > > > to be used later .This is when invoking command options such >> > > > > as >> > > > > dgst sign -in "text" -keyform ENG. >> > > > > With engines' architecture this is possible by passing option - >> > > > > keyform ENG to dgst command. The string in that case is not >> > > > > interpreted as a file path and just passed through. >> > > > > There was engine_set_load_privkey_function that was getting >> > > > > this >> > > > > string. >> > > > > How can I achieve this now with the provider architecture ? If >> > > > > I >> > > > > pass -keyform ENG to dgst command together with --provider , it >> > > > > says "no engine specified to load private key" Should I use >> > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . >> > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I >> > > don't >> > > > > have a real private key info to load and use from a Filesystem. >> > > > > Is there anything to set in the KEYMGMT too ? I can see there >> > > > > is >> > > a >> > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key >> > > > > data in a key object should be considered. Not really sure if >> > > this >> > > > > is something I should set or not and how this keymgmt operation >> > > > > relates with storemgmt operation. >> > > > > >> > > > > thank you if you can send some comment on this. >> > > > > >> > > >> >> -- >> Tom?? Mr?z >> No matter how far down the wrong road you've gone, turn back. >> Turkish proverb >> [You'll know whether the road is wrong if you carefully listen to your >> conscience.] >> >> [https://softgent.com/wp-content/uploads/2020/01/Zasob-14.png] Softgent Sp. z o.o., Budowlanych 31d, 80-298 Gdansk, POLAND KRS: 0000674406, NIP: 9581679801, REGON: 367090912 www.softgent.com S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego Rejestru S?dowego KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci. Jeste?my uczestnikiem Programu RZETELNA Firma Sprawd? nasz? rzetelno?? na https://www.rzetelnafirma.pl/F5IA32UW -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Tue Oct 12 22:37:45 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Tue, 12 Oct 2021 18:37:45 -0400 Subject: openssl 3.0.0 get ECC public key modulus from EVP_PKEY Message-ID: In pre-3.0.0, I used this, omitting the error checking, malloc, ... ecPoint = EC_KEY_get0_public_key(ecKey); ecGroup = EC_KEY_get0_group(ecKey); EC_POINT_point2oct(ecGroup, ecPoint, POINT_CONVERSION_UNCOMPRESSED, *modulusBin, *modulusBytes, NULL); In 3.0.0, I tried this, expecting to get a BIGNUM and then convert irc = EVP_PKEY_get_bn_param(eccKey, OSSL_PKEY_PARAM_PUB_KEY, (BIGNUM **)pub); It returns 0. What's the correct way to get the uncompressed ECC public key? From philipp_subx at redfish-solutions.com Tue Oct 12 23:32:02 2021 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Tue, 12 Oct 2021 17:32:02 -0600 Subject: Creating a CSR using OpenSSL v1.1.1 In-Reply-To: <979bd99b-d71b-8f7a-58ce-09519c65f50c@openssl.org> References: <979bd99b-d71b-8f7a-58ce-09519c65f50c@openssl.org> Message-ID: <2FCB8F40-7AA4-4294-AB89-C0D49BA4C496@redfish-solutions.com> > On Apr 29, 2021, at 8:15 AM, Matt Caswell wrote: > > > On 29/04/2021 15:04, Joe Eremita wrote: >> datasig_len = i2d_X509_REQ_INFO( req->req_info, NULL ); > > You can achieve this by instead doing: > > datasig_len = i2d_re_X509_REQ_tbs(req, NULL); > > See: > > https://www.openssl.org/docs/man1.1.1/man3/i2d_re_X509_REQ_tbs.html > > Matt Is there demo code for creating a CSR? demos/x509/mkreq.c seems to have gone away a while ago... Thanks! From dev at ddvo.net Wed Oct 13 05:44:10 2021 From: dev at ddvo.net (David von Oheimb) Date: Wed, 13 Oct 2021 07:44:10 +0200 Subject: Creating a CSR using OpenSSL v1.1.1 In-Reply-To: <2FCB8F40-7AA4-4294-AB89-C0D49BA4C496@redfish-solutions.com> References: <979bd99b-d71b-8f7a-58ce-09519c65f50c@openssl.org> <2FCB8F40-7AA4-4294-AB89-C0D49BA4C496@redfish-solutions.com> Message-ID: On 13.10.21 01:32, Philip Prindeville wrote: > Is there demo code for creating a CSR? > > demos/x509/mkreq.c seems to have gone away a while ago... > > Thanks! What I generally take as demo/sample code is the OpenSSL apps implementation in apps/ , though that can be rather complicated due to many options, which also holds for apps/req.c . You can follow there the code sections starting with the call to X509_REQ_new_ex(). Sometimes interesting code snippets may be found also in test/ , but not for CSR generation. ??? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From santantonioswap at gmail.com Wed Oct 13 09:13:50 2021 From: santantonioswap at gmail.com (Antonio Santagiuliana) Date: Wed, 13 Oct 2021 10:13:50 +0100 Subject: Store Mgmt and keys loading ( keyform ENG ) In-Reply-To: References: <4995f73c7e4532d40556d934f67272f26fdbf293.camel@openssl.org> <033cf963496decbca923af5d8ba4b1781ac1fd65.camel@openssl.org> Message-ID: Piotr, I can see what you mean now during debugging. I have now managed to set the flags in the RSA structure, not only in the RSA_METHOD. One point I noticed is that you need to explicitly fill in all of the methods in RSA_METHOD now , so those that you don't want to override must be got from the default and set them accordingly in RSA_METHOD structure. I still have to pass back a valid key to dgst's callback from the store mgmt's load() otherwise the call chain complains for missing key. This shouldn't be needed in my opinion if RSA_FLAG_EXT_PKEY is set . On Tue, Oct 12, 2021 at 1:35 PM Piotr Lobacz wrote: > I'm sorry i cannot help you with providers. All i can tell you, is that in > my case libpkcs11 was not setting using RSA_meth_set_flags but > RSA_set_flags and in dotnet openssl implementation, the check was being > made on the method. I was thinking that our issues may be related. > > BR > Piotr > ------------------------------ > *Od:* Antonio Santagiuliana > *Wys?ane:* wtorek, 12 pa?dziernika 2021 10:50 > *Do:* Piotr Lobacz ; openssl-users at openssl.org > > *Temat:* Re: Store Mgmt and keys loading ( keyform ENG ) > > in general, I think that despite what I read in previous replies, > with the operation: > dgst --provider=myprovider -sign handle:1 > is not possible to fully reproduce what was possible with engines : > dgst -keyform ENG sign -in 1 -engine=myengine. > In the case of provider the store manager's caller sets > ossl_store_handle_load_result as fixed callback method when calling the > load of store mgmt. If that callback is not called , it will complain as no > private key is possible to read. > > > On Tue, Oct 12, 2021 at 9:22 AM Antonio Santagiuliana < > santantonioswap at gmail.com> wrote: > > Thank you for the suggestion. > I am using providers though, not engine, and I can't see the higher level > checking this RSA flags before it has detected a valid key is passed back > from the store manager to ossl_store_handle_load_result() ( the callback > passed to the store mgmt load() method). > If I don't call the callback ossl_store_handle_load_result the higher > level after the store mgmt load() complains no private key can be read. > If I pass back an RSA key generated on the fly in the store mgmt load() > then the ossl_store_handle_load_result() is fine using the RSA key mgmt > load finds error in checking RSA flags , I think these flags are not set > but I don't know how to set them in the fictitious private key I generated > on the fly in the store mgmt load() with > EVP_PKEY *pkey = NULL; > pkey = EVP_RSA_gen(2048); > This produces a valid pkey without errors but I think the rsa fields are > not filled in.How can I add them to pkey ? > I think I should register a different keymgmt on my provider but I am not > sure what it should do in my case. > So , for now, the RSA keymgmt is called and in its load() function > ( rsa_load() ) at some point it wants to check RSA_check_flags() and there > it stops as the rsa struct fileds referenced are not filled in. > > > > On Fri, 8 Oct 2021, 22:04 Piotr Lobacz, wrote: > > Hi Antonio, > I was discussing about this problem about half a year ago in here. The > problem was itself in .net library but it concerned RSA_FLAG_EXT_PKEY in > RSA_METHOD which is wrong. Yo can read it in here > https://github.com/dotnet/runtime/issues/53345. The clue of my problem > was that this flag was being set by the dotnet and engine was setting it in > RSA_set_flags - which is the proper way. You need to verify how the engine > sets this flag and read my issue maybe it will help you in solving yours. > > BR > Piotr > ------------------------------ > *Od:* openssl-users w imieniu > u?ytkownika Antonio Santagiuliana > *Wys?ane:* pi?tek, 8 pa?dziernika 2021 10:34 > *Do:* Tomas Mraz > *DW:* openssl-users at openssl.org > *Temat:* Re: Store Mgmt and keys loading ( keyform ENG ) > > Could I ask you what is the best way to let the Openssl carry on in the > case I can't pass the private key from my store manager load() function as > key is offloaded in secure hw? > I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the > callback function from my Store Mgmt's load() where I get the uri ( the > callback func is ossl_store_handle_load_result() ) I get error "could not > read the private key". > If instead I call the callback func , I don't know how to fill in its > params , as I don't have the private key. What should I put in the params > to let the rest of call chain ( I am on the dgst command ) not caring about > private key but carry on with operation?or can I avoid calling the callback? > Thank you > > On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana, < > santantonioswap at gmail.com> wrote: > > It is because of prototypes of methods.. > > On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, < > santantonioswap at gmail.com> wrote: > > Hello, > just continuing on this.. > I defined my store mgmt as : > static const OSSL_ALGORITHM test_store[] = { > { "handle", "provider=test", mystore_functions}, > {NULL, NULL, NULL} > }; > > echo "test" | LD_LIBRARY_PATH=. apps/openssl dgst > --provider-path=./providers --provider=test --sign handle:1 -out > messa.encrypted.bin > > Could not open file or uri for loading private key from handle:1 > > C0628C24787F0000:error:16000069:STORE > routines:ossl_store_get0_loader_int:unregistered > scheme:crypto/store/store_register.c:237:scheme=file > > C0628C24787F0000:error:1608010C:STORE > routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No > store loader found. For standard store loaders you need at least one > of the default or base providers available. Did you forget to load > them? Info: Global default library context, Scheme (file : 0), > Properties () > > C0628C24787F0000:error:16000069:STORE > routines:ossl_store_get0_loader_int:unregistered > scheme:crypto/store/store_register.c:237:scheme=handle > > 1) It firstly looks for a provider for scheme file: and it doesn't > find as I haven't set up any store mgmt for file: . > > 2) It looks like on second attempt it tries to look for handle: but it > finds it not registered. What does this error mean ? Does it look for > registered uri schemes online ? if that is the case how can this works > instead : https://github.com/tpm2-software/tpm2-openssl ? They use > handle: scheme as well. > > Does this mean it's a problem of the methods I registered for the > store or is something related to the uri scheme I am using ? > Sorry but I couldn't find more info on this in the sources/docs . > > > thank you > > > > On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana > wrote: > > > > OK, thank you very much for your comments, that's clear. > > > > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote: > >> > >> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already > >> modified to use OSSL_STORE API to load keys. So you do not need to > >> specify keyform=ENGINE if your key is provided by a provider that > >> supports the STORE functionality for some special URL scheme. You just > >> specify the right URL with that scheme to reference the key in the > >> provider. > >> > >> Of course third party applications need to be modified to call > >> OSSL_STORE API in a similar way how the openssl application does it. > >> > >> Tomas > >> > >> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: > >> > Thank you for your comment. > >> > Am I wrong then in saying that dgst and possibly other apps are not > >> > ready to be used with providers rather than engines in the case you > >> > need keyform=ENGINE ? > >> > > >> > > >> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: > >> > > You would have to implement a STORE provider that handles your > >> > > special > >> > > url scheme and then the keys would be referenced by the > >> > > yourscheme://any-identifier-you-have. Of course the application > >> > > (i.e., > >> > > the openssl application which already does this) would have to use > >> > > the > >> > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER > >> > > API > >> > > or the d2i/PEM_read APIs. > >> > > > >> > > Tomas > >> > > > >> > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: > >> > > > I checked the sources, I found that keyform cannot be set to > >> > > > ENGINE > >> > > > if engine is not specified in the command options, this is in the > >> > > > function make_engine_url() called from load_key() when > >> > > > format==FORMAT_ENGINE. > >> > > > I am not specifying engine in the dgst command options as I am > >> > > using > >> > > > a provider. > >> > > > I would like to achieve the same as FORMAT_ENGINE does, but with > >> > > > provider. > >> > > > > >> > > > > >> > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, > >> > > > wrote: > >> > > > > Hello, > >> > > > > I am doing my own provider starting from the default provider's > >> > > > > code. > >> > > > > I have now a question, I am seeing the STOREMGMT operation is > >> > > > > required to interpret the URI of input private key, I would > >> > > > > like > >> > > > > that the string passed by the user for input key is not > >> > > > > interpret > >> > > > > as file to open but just my provider should save the string > >> > > > > value > >> > > > > to be used later .This is when invoking command options such > >> > > > > as > >> > > > > dgst sign -in "text" -keyform ENG. > >> > > > > With engines' architecture this is possible by passing option - > >> > > > > keyform ENG to dgst command. The string in that case is not > >> > > > > interpreted as a file path and just passed through. > >> > > > > There was engine_set_load_privkey_function that was getting > >> > > > > this > >> > > > > string. > >> > > > > How can I achieve this now with the provider architecture ? If > >> > > > > I > >> > > > > pass -keyform ENG to dgst command together with --provider , it > >> > > > > says "no engine specified to load private key" Should I use > >> > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . > >> > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I > >> > > don't > >> > > > > have a real private key info to load and use from a Filesystem. > >> > > > > Is there anything to set in the KEYMGMT too ? I can see there > >> > > > > is > >> > > a > >> > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key > >> > > > > data in a key object should be considered. Not really sure if > >> > > this > >> > > > > is something I should set or not and how this keymgmt operation > >> > > > > relates with storemgmt operation. > >> > > > > > >> > > > > thank you if you can send some comment on this. > >> > > > > > >> > > > >> > >> -- > >> Tom?? Mr?z > >> No matter how far down the wrong road you've gone, turn back. > >> Turkish proverb > >> [You'll know whether the road is wrong if you carefully listen to your > >> conscience.] > >> > >> > > > > *Softgent Sp. z o.o.*, Budowlanych 31d, 80-298 Gdansk, POLAND > > KRS: 0000674406, NIP: 9581679801, REGON: 367090912 > www.softgent.com > > S?d Rejonowy Gda?sk-P??noc w Gda?sku, VII Wydzia? Gospodarczy Krajowego > Rejestru S?dowego > > KRS 0000674406, Kapita? zak?adowy: 25 000,00 z? wp?acony w ca?o?ci. > > Jeste?my uczestnikiem Programu > *RZETELNA* *Firma * > Sprawd? nasz? rzetelno?? na > https://www.rzetelnafirma.pl/F5IA32UW > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetson23 at hotmail.com Wed Oct 13 14:32:10 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Wed, 13 Oct 2021 14:32:10 +0000 Subject: Client side session handling Message-ID: I?m not sure I fully understand client-side sessions in OpenSSL. My understanding is that on the server side, OpenSSL internally handles managing sessions. On the client side, they need to be handled by the application. This is true for both TLS 1.3 and TLS 1.2 (and prior), even though both protocols handle sessions slightly differently. I?ll try to keep my questions to the simplest case and not get into how I store off the session objects and re-use them. But basically, I save each session object (2 of them per long handshake in this case) for client connections. I am able to successfully re-use them to initiate a short handshake. I have a remove callback set up that basically just prints something so I can see what OpenSSL is doing. After the SESSION object is used on the client side, I call SSL_SESSION_free() on that session. If I don?t use the client-side session, I also call SSL_SESSION_free() when the session times out and is no longer presumable, checking for that with SSL_SESSION_is_resumable(). Everything works fine, short handshakes are done when I expect them to be, etc. The confusing part is that given everything above, when I free the SSL_CTX associated with these connections/sessions, I see the remove callback function get called again for client-side sessions that I already called SSL_SESSION_free() on. Is this normal behavior? Is there something else I?m missing? Thanks in advance. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 13 16:06:21 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 13 Oct 2021 17:06:21 +0100 Subject: openssl 3.0.0 get ECC public key modulus from EVP_PKEY In-Reply-To: References: Message-ID: On 12/10/2021 23:37, Ken Goldman wrote: > In pre-3.0.0, I used this, omitting the error checking, malloc, ... > > ????ecPoint = EC_KEY_get0_public_key(ecKey); > ????ecGroup = EC_KEY_get0_group(ecKey); > ????EC_POINT_point2oct(ecGroup, ecPoint, > ?????????????? POINT_CONVERSION_UNCOMPRESSED, > ?????????????? *modulusBin, *modulusBytes, NULL); > > In 3.0.0, I tried this, expecting to get a BIGNUM and then convert > > ??????? irc = EVP_PKEY_get_bn_param(eccKey, OSSL_PKEY_PARAM_PUB_KEY, > (BIGNUM **)pub); > > It returns 0. > > What's the correct way to get the uncompressed ECC public key? > Refer to this man page: https://www.openssl.org/docs/man3.0/man7/EVP_PKEY-EC.html For an EC key, the public key parameter is: "pub" (OSSL_PKEY_PARAM_PUB_KEY) The public key value in EC point format. You will note that this is an octet string and not an integer which is why EVP_PKEY_get_bn_param is failing. Alternatively you could get the x and y components of the public key separately using: "qx" (OSSL_PKEY_PARAM_EC_PUB_X) Used for getting the EC public key X component. "qy" (OSSL_PKEY_PARAM_EC_PUB_Y) Used for getting the EC public key Y component. In this case EVP_PKEY_get_bn_param would be appropriate. Matt From openssl-users at dukhovni.org Wed Oct 13 18:13:47 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 13 Oct 2021 14:13:47 -0400 Subject: Client side session handling In-Reply-To: References: Message-ID: On Wed, Oct 13, 2021 at 02:32:10PM +0000, Jason Schultz wrote: > The confusing part is that given everything above, when I free the > SSL_CTX associated with these connections/sessions, I see the remove > callback function get called again for client-side sessions that I > already called SSL_SESSION_free() on. Is this normal behavior? Is > there something else I?m missing? OpenSSL SSL_SESSSIONS are reference-counted. This is typical of a number of similar sufficiently complex structures for which it makes more sense to bump a reference counter than to make a copy. The SSL_SESSION_free(3), X509_free(), and various other calls just decrement the reference counter, with the object only actually freed once the counter reaches 0. Various functions (though not all, as documented for each function) that return such objects to the application increment the refernce counter (say initially from 1 to 2), and the application is then responsible for decrementing it. THe object is finally freed when any internal reference is released (if that happens last). The internal store of client-side sessions is not used by OpenSSL for anything other than asking the application to remove sessions when the cache exceeds some limit, the application still needs its own cache lookup mechanism and its own separat cache (of the same shared by reference count underlying objects), all the OpenSSL cache is doing for you is "helping" you keep the cache size bounded. In Postfix we serialise session objects into a cache in which they are not shared with OpenSSL and manage expunging stale sessions independently of OpenSSL. We therefore tell OpenSSL to not bother maintaining an internal cache. SSL_CTX_set_session_cache_mode(client_ctx, SSL_SESS_CACHE_CLIENT | SSL_SESS_CACHE_NO_INTERNAL_STORE | SSL_SESS_CACHE_NO_AUTO_CLEAR); All the work of managing session storage and lookup is done by the callback: SSL_CTX_sess_set_new_cb(client_ctx, new_client_session_cb); There's no remove callback, we handle cache management outside OpenSSL.. -- Viktor. From kgoldman at us.ibm.com Wed Oct 13 20:12:42 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 13 Oct 2021 16:12:42 -0400 Subject: openssl 3.0.0 get ECC public key modulus from EVP_PKEY In-Reply-To: References: Message-ID: On 10/13/2021 12:06 PM, Matt Caswell wrote: > > On 12/10/2021 23:37, Ken Goldman wrote: >> In pre-3.0.0, I used this, omitting the error checking, malloc, ... >> >> ????ecPoint = EC_KEY_get0_public_key(ecKey); >> ????ecGroup = EC_KEY_get0_group(ecKey); >> ????EC_POINT_point2oct(ecGroup, ecPoint, >> ?????????????? POINT_CONVERSION_UNCOMPRESSED, >> ?????????????? *modulusBin, *modulusBytes, NULL); >> >> In 3.0.0, I tried this, expecting to get a BIGNUM and then convert >> >> ??????? irc = EVP_PKEY_get_bn_param(eccKey, OSSL_PKEY_PARAM_PUB_KEY, (BIGNUM **)pub); >> >> It returns 0. >> >> What's the correct way to get the uncompressed ECC public key? >> > Refer to this man page: > > https://www.openssl.org/docs/man3.0/man7/EVP_PKEY-EC.html > > For an EC key, the public key parameter is: > > "pub" (OSSL_PKEY_PARAM_PUB_KEY) > The public key value in EC point format. > > You will note that this is an octet string and not an integer which is why EVP_PKEY_get_bn_param is failing. I tried irc = EVP_PKEY_get_octet_string_param(eccKey, OSSL_PKEY_PARAM_PRIV_KEY, *priv, 256, (size_t *)privLen); which failed. In common_get_params() the eccKey is cast to an EC_KEY and there are BIGNUMs for X,Y,Z. The EC_GROUP looks populated. It fails on (p = OSSL_PARAM_locate(params, OSSL_PKEY_PARAM_EC_DECODED_FROM_EXPLICIT_PARAMS)) > > Alternatively you could get the x and y components of the public key separately using: > > "qx" (OSSL_PKEY_PARAM_EC_PUB_X) > Used for getting the EC public key X component. > > "qy" (OSSL_PKEY_PARAM_EC_PUB_Y) > Used for getting the EC public key Y component. > > In this case EVP_PKEY_get_bn_param would be appropriate. > > Matt > > > > > From jetson23 at hotmail.com Wed Oct 13 23:57:14 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Wed, 13 Oct 2021 23:57:14 +0000 Subject: Client side session handling In-Reply-To: References: Message-ID: OpenSSL SSL_SESSSIONS are reference-counted. This is typical of a number of similar sufficiently complex structures for which it makes more sense to bump a reference counter than to make a copy. The SSL_SESSION_free(3), X509_free(), and various other calls just decrement the reference counter, with the object only actually freed once the counter reaches 0. Various functions (though not all, as documented for each function) that return such objects to the application increment the refernce counter (say initially from 1 to 2), and the application is then responsible for decrementing it. THe object is finally freed when any internal reference is released (if that happens last). --- Hi Viktor. Thanks for your reply. I'm somewhat familiar with the reference count stuff from reading the doc on these (and other) functions. But it sounds like the behavior I'm seeing is expected, and OpenSSL is doing the actual free of the SSL_SESSION when the SSL_CTX is freed. Is that accurate? Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Oct 14 02:24:21 2021 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 13 Oct 2021 22:24:21 -0400 Subject: Client side session handling In-Reply-To: References: Message-ID: On Wed, Oct 13, 2021 at 11:57:14PM +0000, Jason Schultz wrote: > I'm somewhat familiar with the reference count stuff from reading the > doc on these (and other) functions. But it sounds like the behavior > I'm seeing is expected, and OpenSSL is doing the actual free of the > SSL_SESSION when the SSL_CTX is freed. That's plausibly the case, barring bugs in your application, yes either freeing some handle too many or too few times. -- Viktor. From matt at openssl.org Thu Oct 14 10:39:06 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 14 Oct 2021 11:39:06 +0100 Subject: openssl 3.0.0 get ECC public key modulus from EVP_PKEY In-Reply-To: References: Message-ID: <6bb8a3df-a0f0-a8f5-d65a-9d4a1d947591@openssl.org> On 13/10/2021 21:12, Ken Goldman wrote: > > I tried > > ??????? irc = EVP_PKEY_get_octet_string_param(eccKey, > OSSL_PKEY_PARAM_PRIV_KEY, > ????????????????????????? *priv, 256, (size_t *)privLen); > > which failed. In your original email you were attempting to access OSSL_PKEY_PARAM_PUB_KEY as a BIGNUM which (correctly) failed because it is an octet string. Now you are trying to access OSSL_PKEY_PARAM_PRIV_KEY as an octet string which is (correctly) going to fail because it is an integer. From the same man page I previously referenced: "priv" (OSSL_PKEY_PARAM_PRIV_KEY) The private key value. Since its an integer using EVP_PKEY_get_bn_param() would be appropriate here, but not EVP_PKEY_get_octet_string_param(). Basically you need to know the type of the parameter you are attempting to access and use the right kind of "getter" to match the type - otherwise it will fail. Matt From philipp_subx at redfish-solutions.com Thu Oct 14 16:43:57 2021 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 14 Oct 2021 10:43:57 -0600 Subject: Examples of adding Private Enterprise Numbers (PEN's) Extensions to CSR Message-ID: <18D96C8E-E1C7-4A71-8EE5-53DA17E80667@redfish-solutions.com> Hi, I need to generate CSR's with some Extensions included that use our PEN's as allocated by IANA. Are there any examples of this? Also, I'm looking at X509_REQ_add_extensions_nid() and it takes a STACK_OF(X509_EXTENSION) but it doesn't seem to actually iterate through the stack... Is this code even correct? What am I missing? Ditto for X509_REQ_add_extensions(). Thanks, -Philip From kgoldman at us.ibm.com Thu Oct 14 21:36:48 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Thu, 14 Oct 2021 17:36:48 -0400 Subject: openssl 3.0.0 get ECC public key modulus from EVP_PKEY In-Reply-To: <6bb8a3df-a0f0-a8f5-d65a-9d4a1d947591@openssl.org> References: <6bb8a3df-a0f0-a8f5-d65a-9d4a1d947591@openssl.org> Message-ID: On 10/14/2021 6:39 AM, Matt Caswell wrote: > > "priv" (OSSL_PKEY_PARAM_PRIV_KEY) > > The private key value. > > Since its an integer using EVP_PKEY_get_bn_param() would be appropriate here, but not EVP_PKEY_get_octet_string_param(). > > Basically you need to know the type of the parameter you are attempting to access and use the right kind of "getter" to match the type - otherwise it will fail. That helped! https://www.openssl.org/docs/manmaster/man7/EVP_PKEY-EC.html I found that page a bit confusing. Is it right that are all actually BIGNUM? I.e., not C int or unsigned int? ~~~~~~~~~~~~~~~~ While I'm on that page: should call EVP_PKEY_get_utf8_string_param(). This seems to require an allocated array. How does one find the size to allocate? Does it follow the typical "if buf is NULL, return just the size" so it can be malloced. same question. From tomas at openssl.org Fri Oct 15 06:34:12 2021 From: tomas at openssl.org (Tomas Mraz) Date: Fri, 15 Oct 2021 08:34:12 +0200 Subject: openssl 3.0.0 get ECC public key modulus from EVP_PKEY In-Reply-To: References: <6bb8a3df-a0f0-a8f5-d65a-9d4a1d947591@openssl.org> Message-ID: <1ade468ba3011405bf7baf743da51fd816aced44.camel@openssl.org> On Thu, 2021-10-14 at 17:36 -0400, Ken Goldman wrote: > On 10/14/2021 6:39 AM, Matt Caswell wrote: > > > > "priv" (OSSL_PKEY_PARAM_PRIV_KEY) > > > > The private key value. > > > > Since its an integer using EVP_PKEY_get_bn_param() would be > > appropriate here, but not EVP_PKEY_get_octet_string_param(). > > > > Basically you need to know the type of the parameter you are > > attempting to access and use the right kind of "getter" to match > > the type - otherwise it will fail. > > That helped! > > https://www.openssl.org/docs/manmaster/man7/EVP_PKEY-EC.html > > I found that page a bit confusing.? Is it right that > > > > > are all actually BIGNUM?? I.e., not C int or unsigned int? They are unbounded integer values. See OSSL_PARAM(3) > > ~~~~~~~~~~~~~~~~ > > While I'm on that page: > > should call EVP_PKEY_get_utf8_string_param().? This > seems to require an allocated array. > How does one find the size to allocate?? Does it follow the typical > "if buf is NULL, return just the size" > so it can be malloced. > > same question. Yes, this should work, except for one caveat - you need to allocate + 1 byte for \0 terminator in case of the UTF8 string. We should document this. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From armin.novak at thincast.com Fri Oct 15 11:56:37 2021 From: armin.novak at thincast.com (Armin Novak) Date: Fri, 15 Oct 2021 13:56:37 +0200 Subject: Disable installation of docs Message-ID: Hi, I need to deploy custom builds for OpenSSL for some packages I maintain (flatpak/snap/windows/mac/...) Most of the build/install time is spent installing the /usr/share/doc stuff, which is not used in that case anyway. Is there some configuration option to disable this without the need to patch the build system? regards Armin From matt at openssl.org Fri Oct 15 12:05:17 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 15 Oct 2021 13:05:17 +0100 Subject: Disable installation of docs In-Reply-To: References: Message-ID: <61a3e892-28cd-8889-26dc-b698b4a661d3@openssl.org> Instead of: make install Do: make install_sw install_ssldirs Matt On 15/10/2021 12:56, Armin Novak wrote: > Hi, > > > I need to deploy custom builds for OpenSSL for some packages I maintain > (flatpak/snap/windows/mac/...) > > Most of the build/install time is spent installing the /usr/share/doc > stuff, which is not used in that case anyway. > > > Is there some configuration option to disable this without the need to > patch the build system? > > > regards > > Armin > From jb-openssl at wisemo.com Fri Oct 15 13:06:00 2021 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 15 Oct 2021 15:06:00 +0200 Subject: Examples of adding Private Enterprise Numbers (PEN's) Extensions to CSR In-Reply-To: <18D96C8E-E1C7-4A71-8EE5-53DA17E80667@redfish-solutions.com> References: <18D96C8E-E1C7-4A71-8EE5-53DA17E80667@redfish-solutions.com> Message-ID: On 2021-10-14 18:43, Philip Prindeville wrote: > Hi, > > I need to generate CSR's with some Extensions included that use our PEN's as allocated by IANA. > > Are there any examples of this? > > Also, I'm looking at X509_REQ_add_extensions_nid() and it takes a STACK_OF(X509_EXTENSION) but it doesn't seem to actually iterate through the stack... Is this code even correct? What am I missing? Ditto for X509_REQ_add_extensions(). > > Thanks, > > -Philip > I don't know how to do this via the API, but the source code for the command line tools may give some good clues.? Here is how I would do it with the command line tools: First of all, you need to (administratively) decide how to subdivide your private OID tree belowyour enterprise ID.? This would be a company internal document listing how you use the OIDsand where to put future OIDs of various kinds.? Use whatever document editing system is usedfor other long term company documents.? Something like: Redfish solutions has been allocated the following OID prefix via the IANA "Enterprise numbers"process: RedfishOid = 1.3.6.1.4.1.9999999 We subdivide this as follows: RedfishOid.1 = Redfish X.509 extensions RedfishOid.1.1 = FooBar extension, see design document RS12345 RedfishOid.1.2 = BazQux extension, see design document RS12346 RedfishOid.2 = Redfish SNMP extensions RedfishOid.2.1 = Redfish hardware-box-A SNMP extensions RedfishOid.3 = Redfish contributions to public standardisation efforts RedfishOid.4 = Redfish internal LDAP extensions used by HR Next for the OpenSSL command line tools, you need to add the individual X.509 relatedOIDs to the openssl.cnf file: In the [default] section: oid_section = new_oids In the [new_oids] section RedFishFooBar=1.3.6.1.4.1.9999999.1.1 RedFishBazQux=1.3.6.1.4.1.9999999.1.2 From there, you should be able to use the new OID names in relevant sections and options, using the generic syntax that explicitly states how each value needs to beencoded. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From vishals1991 at gmail.com Wed Oct 20 09:56:39 2021 From: vishals1991 at gmail.com (Vishal Sinha) Date: Wed, 20 Oct 2021 15:26:39 +0530 Subject: Query reg. using certificates bigger than 4k for EAP-TLS Message-ID: Hi We are using openssl 1.1.1c version on our client and server. Client and Server are doing EAP-TLS authentication using certificates which are more than 4k in size (using 1 root CA and 2 intermediate CAs). We noticed that the server is not able to handle it gracefully due to insufficient buffer size during SSL handshake and hence authentication fails. To solve this issue, we increased the buffer size to 8k programmatically and authentication passed. Is there any other way to solve this problem? Regards Vishal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sanjeev.Kumar-Mishra at rbbn.com Wed Oct 20 09:57:02 2021 From: Sanjeev.Kumar-Mishra at rbbn.com (Kumar Mishra, Sanjeev) Date: Wed, 20 Oct 2021 09:57:02 +0000 Subject: Help Required For Code Changes While Upgrading OpenSSL 1.0.1 to 3.0 Message-ID: Hi, I am upgrading the code from OpenSSL 1.0.1 to 3.0. I am getting following compilation errors. Could you please suggest appropriate changes for following- 1. X509err(X509_F_X509_STORE_ADD_CERT,ERR_R_MALLOC_FAILURE); error: 'X509err' was not declared in this scope 2. RSA *rsa = RSA_new(); error: 'rsa' was not declared in this scope 3. if(EVP_PKEY_set1_RSA(pkey, rsa)) error: 'EVP_PKEY_set1_RSA' was not declared in this scope 4. RSA_free(rsa); error: 'RSA_free' was not declared in this scope 5. RSA *rsa = EVP_PKEY_get1_RSA(privKey); error: 'EVP_PKEY_get1_RSA' was not declared in this scope 6. if(PEM_write_bio_RSA_PUBKEY(bio, rsa)) error: 'PEM_write_bio_RSA_PUBKEY' was not declared in this scope 7. RSA_get0_key(rsa, &n, NULL, NULL); error: 'RSA_get0_key' was not declared in this scope Thanking You In Anticipation, Sanjeev Kumar Mishra Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 20 10:22:14 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Oct 2021 11:22:14 +0100 Subject: Query reg. using certificates bigger than 4k for EAP-TLS In-Reply-To: References: Message-ID: On 20/10/2021 10:56, Vishal Sinha wrote: > We are using openssl 1.1.1c version on our client and server. Client and > Server are doing EAP-TLS authentication using certificates which are > more than 4k in size (using 1 root CA and 2 intermediate CAs). We > noticed that the server is not able to handle it gracefully due to > insufficient buffer size during SSL handshake and hence authentication > fails. To solve this issue, we increased the buffer size to 8k > programmatically and authentication passed. Is there any other way to > solve this problem? Which buffer did you change? Do you have an example certificate that is shareable? Is it the certificate that is too large, or the whole chain? Matt From Sunil.Paramashivaiah at rbbn.com Wed Oct 20 10:41:05 2021 From: Sunil.Paramashivaiah at rbbn.com (Paramashivaiah, Sunil) Date: Wed, 20 Oct 2021 10:41:05 +0000 Subject: Need help to get members of SSL_SESSION in openssl 3.0 Message-ID: Hi All, Please let me know APIs to get members(ssl_version, session_id, references and session_id_length) of SSL_SESSION structure variable. Thanks and Regards, Sunil Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 20 10:44:01 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Oct 2021 11:44:01 +0100 Subject: Help Required For Code Changes While Upgrading OpenSSL 1.0.1 to 3.0 In-Reply-To: References: Message-ID: On 20/10/2021 10:57, Kumar Mishra, Sanjeev wrote: > Hi, > I am upgrading the code from OpenSSL 1.0.1 to 3.0. I am getting > following compilation errors. Could you please suggest appropriate > changes for following- > > 1. X509err(X509_F_X509_STORE_ADD_CERT,ERR_R_MALLOC_FAILURE);???error: > 'X509err' was not declared in this scope > 2. ?RSA *rsa = RSA_new(); error: 'rsa' was not declared in this scope > 3. if(EVP_PKEY_set1_RSA(pkey, rsa)) error: 'EVP_PKEY_set1_RSA' was not > declared in this scope > 4. ?RSA_free(rsa); error: 'RSA_free' was not declared in this scope > 5. RSA *rsa = EVP_PKEY_get1_RSA(privKey); error: 'EVP_PKEY_get1_RSA' > was not declared in this scope > 6. ?if(PEM_write_bio_RSA_PUBKEY(bio, rsa)) error: > 'PEM_write_bio_RSA_PUBKEY' was not declared in this scope > 7. ?RSA_get0_key(rsa, &n, NULL, NULL);?error: 'RSA_get0_key' was not > declared in this scope Did you build OpenSSL using the "no-deprecated" option? The errors suggest the compiler cannot find the declarations of the various functions. Assuming you are actually including the correct header files then this would normally only occur as a result of "no-deprecated". In a normal build the functions still exist even in 3.0 - they are just deprecated. To use non-deprecated functions instead: Instead of X509err you can use: ERR_raise(ERR_LIB_X509, ERR_R_MALLOC_FAILURE) It seems strange for you to have been raising an error for X509_F_X509_STORE_ADD_CERT, since this is indicates the error occurred in an internal OpenSSL function...but in any case we no longer use the _F_ codes. Instead of creating an RSA key via RSA_new() and setting it in an EVP_PKEY via EVP_PKEY_set1_RSA() you need to create an EVP_PKEY directly. How to do this depends on where you were getting your RSA data from before. For example if you were loading an RSA private key from a file then you might use PEM_read_bio_PrivateKey() to load the EVP_PKEY directly: https://www.openssl.org/docs/man3.0/man3/PEM_read_bio_PrivateKey.html Or if you were loading it from individual data fields (p, q, e, d, etc) then you might use EVP_PKEY_fromdata: https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html https://www.openssl.org/docs/man3.0/man7/EVP_PKEY-RSA.html Or if you were generating a new one then you might use EVP_PKEY_keygen: https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_keygen.html Instead of PEM_write_bio_RSA_PUBKEY() you probably want PEM_write_bio_PUBKEY() https://www.openssl.org/docs/man3.0/man3/PEM_write_bio_PUBKEY.html Instead of RSA_get0_key() to get hold of "n" you can use EVP_PKEY_get_bn_param: https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_get_bn_param.html Matt From matt at openssl.org Wed Oct 20 10:47:55 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Oct 2021 11:47:55 +0100 Subject: Need help to get members of SSL_SESSION in openssl 3.0 In-Reply-To: References: Message-ID: On 20/10/2021 11:41, Paramashivaiah, Sunil wrote: > Hi All, > > ??????Please let me know APIs to get members(ssl_version, session_id, > references and session_id_length) of SSL_SESSION structure variable. For ssl_version you can use SSL_SESSION_get_protocol_version. For session_id/session_id_length you can use SSL_SESSION_get_id(). The references value is considered internal. You cannot access that. Matt From vishals1991 at gmail.com Wed Oct 20 11:34:59 2021 From: vishals1991 at gmail.com (Vishal Sinha) Date: Wed, 20 Oct 2021 17:04:59 +0530 Subject: Query reg. using certificates bigger than 4k for EAP-TLS In-Reply-To: References: Message-ID: Hi Matt The certificate is not large as such. But since it's a chain, the overall size crosses 4k. We used BIO_set_write_buffer_size() API to increase the size from 4k to 8k of the BIO buffer in SSL context. Regards Vishal On Wed, Oct 20, 2021 at 3:26 PM Vishal Sinha wrote: > Hi > > We are using openssl 1.1.1c version on our client and server. Client and > Server are doing EAP-TLS authentication using certificates which are more > than 4k in size (using 1 root CA and 2 intermediate CAs). We noticed that > the server is not able to handle it gracefully due to insufficient buffer > size during SSL handshake and hence authentication fails. To solve this > issue, we increased the buffer size to 8k programmatically and > authentication passed. Is there any other way to solve this problem? > > Regards > Vishal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 20 13:30:19 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 20 Oct 2021 14:30:19 +0100 Subject: Query reg. using certificates bigger than 4k for EAP-TLS In-Reply-To: References: Message-ID: Your scenario is still not quite clear to me. It sounds like you are using a BIO_f_buffer() BIO to buffer data. This is on the server side right? Are you encountering this problem for server writes? Since you are talking about the certificate chain, I assume you are referring to the server writing that chain. libssl itself also uses a BIO_f_buffer() internally for writes during the handshake. It's not clear to me whether you are referring to the internal libssl buffering BIO, or one that you have created? Either way, the effect of the buffering BIO during writes is that a 4k buffer is used by default. If data is written that is less than 4k in length then it is held in the buffer until either the BIO is "flushed" or the buffer is filled. In the event the buffer gets filled then it is automatically flushed, and any remaining data gets buffered. The only effect of changing the buffer size should be to decrease the frequency that the buffer gets filled and automatic flushes occur. It sounds like by trying to increase the buffer size you are seeking to avoid "parial" writes where only part of the data is flushed and the remainder is held back for sending later when the buffer is next filled or flushed. This should not normally make any difference to the correct operation of the protocol (except for efficiency) although it does depend on what happens "downstream" of the buffering bio and how partial writes get sent to the peer. It sounds like things are not quite working correctly for you when "partial" writes occur. This sounds like a potential problem in the BIO chain downstream of libssl (i.e. in your application). Matt On 20/10/2021 12:34, Vishal Sinha wrote: > Hi Matt > > The certificate is not large as such. But since it's a chain, the > overall size crosses 4k. We used BIO_set_write_buffer_size() API to > increase the size from 4k to 8k of the BIO buffer in SSL context. > > Regards > Vishal > > > On Wed, Oct 20, 2021 at 3:26 PM Vishal Sinha > wrote: > > Hi > > We are using openssl 1.1.1c version on our client and server. Client > and Server are doing EAP-TLS authentication using certificates which > are more than 4k in size (using 1 root CA and 2 intermediate CAs). > We noticed that the server is not able to handle it gracefully due > to insufficient buffer size during SSL handshake and hence > authentication fails. To solve this issue, we increased the buffer > size to 8k programmatically and authentication passed. Is there any > other way to solve this problem? > > Regards > Vishal > From bkaduk at akamai.com Wed Oct 20 13:38:43 2021 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 20 Oct 2021 06:38:43 -0700 Subject: Query reg. using certificates bigger than 4k for EAP-TLS In-Reply-To: References: Message-ID: <20211020133842.GL6736@akamai.com> I'm also a bit confused at how this became the limiting factor for the application in question. https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert-08 has some discussion of how large certificates can cause issues for EAP (as well as some guidance to EAP deployments as to how to reduce the scale of the issues), which suggests that most of the time there is already some buffering going on at a 1-2k chunk size just based on the limits of the EAP exchange's MTU. (The parties in the exchange have to transmit one chunk at a time and get an ACK back before transmitting the next chunk, and once that handshake flight is finished the process is reversed with the other party sending a chunk at a time.) A BIO-layer buffer would be between that and the libssl handshake buffering, and as you describe, it should still get the data through, just maybe with a slight inefficiency. -Ben On Wed, Oct 20, 2021 at 02:30:19PM +0100, Matt Caswell wrote: > Your scenario is still not quite clear to me. > > It sounds like you are using a BIO_f_buffer() BIO to buffer data. This is on > the server side right? Are you encountering this problem for server writes? > Since you are talking about the certificate chain, I assume you are > referring to the server writing that chain. > > libssl itself also uses a BIO_f_buffer() internally for writes during the > handshake. It's not clear to me whether you are referring to the internal > libssl buffering BIO, or one that you have created? > > Either way, the effect of the buffering BIO during writes is that a 4k > buffer is used by default. If data is written that is less than 4k in length > then it is held in the buffer until either the BIO is "flushed" or the > buffer is filled. In the event the buffer gets filled then it is > automatically flushed, and any remaining data gets buffered. > > The only effect of changing the buffer size should be to decrease the > frequency that the buffer gets filled and automatic flushes occur. It sounds > like by trying to increase the buffer size you are seeking to avoid "parial" > writes where only part of the data is flushed and the remainder is held back > for sending later when the buffer is next filled or flushed. This should not > normally make any difference to the correct operation of the protocol > (except for efficiency) although it does depend on what happens "downstream" > of the buffering bio and how partial writes get sent to the peer. > > It sounds like things are not quite working correctly for you when "partial" > writes occur. This sounds like a potential problem in the BIO chain > downstream of libssl (i.e. in your application). > > Matt > > On 20/10/2021 12:34, Vishal Sinha wrote: > > Hi Matt > > > > The certificate is not large as such. But since it's a chain, the > > overall size crosses 4k. We used BIO_set_write_buffer_size() API to > > increase the size from 4k to 8k of the BIO buffer in SSL context. > > > > Regards > > Vishal > > > > > > On Wed, Oct 20, 2021 at 3:26 PM Vishal Sinha > > wrote: > > > > Hi > > > > We are using openssl 1.1.1c version on our client and server. Client > > and Server are doing EAP-TLS authentication using certificates which > > are more than 4k in size (using 1 root CA and 2 intermediate CAs). > > We noticed that the server is not able to handle it gracefully due > > to insufficient buffer size during SSL handshake and hence > > authentication fails. To solve this issue, we increased the buffer > > size to 8k programmatically and authentication passed. Is there any > > other way to solve this problem? > > > > Regards > > Vishal > > From janjust at nikhef.nl Wed Oct 20 15:46:18 2021 From: janjust at nikhef.nl (Jan Just Keijser) Date: Wed, 20 Oct 2021 17:46:18 +0200 Subject: Query reg. using certificates bigger than 4k for EAP-TLS In-Reply-To: References: Message-ID: Hi Vishal, On 20/10/21 13:34, Vishal Sinha wrote: > Hi Matt > > The certificate is not large as such. But since it's a chain, the > overall size crosses 4k. We used BIO_set_write_buffer_size() API to > increase the size from 4k to 8k of the BIO buffer in SSL context. > > just out of curiosity: does this issue occur with pppd with EAP-TLS support (which I originally added) ? if so, which version of the pppd code are you using or which version of the ppp-eap-tls patch? If you *are* using pppd to do the EAP-TLS handshake then let me try to replicate your particular issue. HTH, JJK > > On Wed, Oct 20, 2021 at 3:26 PM Vishal Sinha > wrote: > > Hi > > We are using openssl 1.1.1c version on our client and server. > Client and Server are doing EAP-TLS authentication using > certificates which are more than 4k in size (using 1 root CA and 2 > intermediate CAs). We noticed that the server is not able to > handle it gracefully due to insufficient buffer size during SSL > handshake and hence authentication fails. To solve this issue, we > increased the buffer size to 8k programmatically and > authentication passed. Is there any other way to solve this problem? > > Regards > Vishal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sunil.Paramashivaiah at rbbn.com Thu Oct 21 08:48:55 2021 From: Sunil.Paramashivaiah at rbbn.com (Paramashivaiah, Sunil) Date: Thu, 21 Oct 2021 08:48:55 +0000 Subject: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 Message-ID: Hi All, Please let me know how I can replace the below 1.0.2 code to 3.0 SSL_SESSION data; SSL_SESSION *ret=NULL; data.ssl_version = sessVersion; data.session_id_length= sessIdLen; memcpy(data.session_id, sessId, sessIdLen); CRYPTO_r_lock(CRYPTO_LOCK_SSL_CTX); ret= (SSL_SESSION *)lh_retrieve((_LHASH *)sslCtx->sessions, &data); CRYPTO_r_unlock(CRYPTO_LOCK_SSL_CTX); Thanks and Regards, Sunil Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Oct 21 09:47:11 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 21 Oct 2021 10:47:11 +0100 Subject: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 In-Reply-To: References: Message-ID: <19353e11-2cd6-fef0-eb22-9ac3d927920e@openssl.org> On 21/10/2021 09:48, Paramashivaiah, Sunil wrote: > Hi All, > > ???????? Please let me know how I can replace the below 1.0.2 code to 3.0 > > *??? SSL_SESSION data;* > > *??? SSL_SESSION *ret=NULL;* > > ** > > *??? data.ssl_version = sessVersion;* > > *??? data.session_id_length= sessIdLen;* > > ** > > *??? memcpy(data.session_id, sessId, ?sessIdLen);* > > *??? CRYPTO_r_lock(CRYPTO_LOCK_SSL_CTX);* > > ** > > *??? ret= (SSL_SESSION *)lh_retrieve((_LHASH *)sslCtx->sessions, &data);* > > ** > > *??? CRYPTO_r_unlock(CRYPTO_LOCK_SSL_CTX);* > I don't think this is currently possible (at least not easily). There is no way to access the session hash lock at the moment. There *is* a way to get hold of the session hash itself using SSL_CTX_sessions(). That's not particularly useful, because without access to the lock you would have to do your own locking to ensure that no libssl functions were being called by other threads at the same time as the retrieval from the hash. Also we don't expose the function lh_SSL_SESSION_retrieve() which is what we use internally for retrieving out of the session hash (this is actually possibly a bug) - although you could use the type generic OPENSSL_LH_retrieve function (lh_retrieve in your code above is just a macro for OPENSSL_LH_retrieve in 3.0) If your objective is simply to determine whether such a hash entry exists or not then you could instead use SSL_has_matching_session_id(): https://www.openssl.org/docs/man3.0/man3/SSL_has_matching_session_id.html Matt From thomas_floodeenjr at mentor.com Thu Oct 21 12:02:00 2021 From: thomas_floodeenjr at mentor.com (Floodeenjr, Thomas) Date: Thu, 21 Oct 2021 12:02:00 +0000 Subject: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 In-Reply-To: References: Message-ID: Here are my notes from when we did this project a couple of years ago. It does not match your code exactly, but maybe it helps. -Tom ### ALL ### Follow the porting instructions here: https://wiki.tizen.org/Security/Tizen_5.X_Migration_from_OpenSSL_1.0.2_to_OpenSSL_1.1.1_guide Especially the section "EVP_CIPHER_CTX became opaque". The changes here will match changes for most classes in OpenSSL. Most notable: Declaration: - EVP_CIPHER_CTX evp; + EVP_CIPHER_CTX *evp; Initialization & cleanup: - EVP_CIPHER_CTX_init(&evp); + evp = EVP_CIPHER_CTX_new(); + EVP_CIPHER_CTX_free(evp); /* do not forget to free after usage or error */ Function calling: - EVP_CipherInit(&evp, EVP_des_cbc(), k1, NULL, enc); + EVP_CipherInit(evp, EVP_des_cbc(), k1, NULL, enc); Note the change to using a pointer instead of directly. For encoding/decoding, the init() step is still needed. - EVP_EncodeInit(&m_evpCtx); + m_evpCtx = EVP_ENCODE_CTX_new(); + EVP_EncodeInit(m_evpCtx); More changes: X509_EXTENSION *ext = X509_get_ext(peer, i); const unsigned char *data; - data = ext->value->data; + data = ASN1_STRING_get0_data(X509_EXTENSION_get_data(ext)); - ext_data = meth->d2i(NULL, &data, ext->value->length); + ext_data = meth->d2i(NULL, &data, ASN1_STRING_length(X509_EXTENSION_get_data(ext))); xmlsec.h(99): warning C4005: 'XMLSEC_CRYPTO': macro redefinition /** * XMLSEC_CRYPTO: * * Macro. Deprecated. Defined for backward compatibility only. Do not use * in your code and use xmlSecGetDefaultCrypto() function instead. * * Returns the default crypto engine. */ #define XMLSEC_CRYPTO (xmlSecGetDefaultCrypto()) ### WINDOWS ### ws2_32.lib will need to replace wsock32.lib when linking, or be added to link if not there. ZLIB_WINAPI may be defined with some OSS (like curl), this causes link errors and should be removed. ### LINUX ### Linux will likely need to link with -lpthread Some apps may need -lrt From: openssl-users On Behalf Of Paramashivaiah, Sunil Sent: Thursday, October 21, 2021 2:49 AM To: openssl-users at openssl.org Subject: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 Hi All, Please let me know how I can replace the below 1.0.2 code to 3.0 SSL_SESSION data; SSL_SESSION *ret=NULL; data.ssl_version = sessVersion; data.session_id_length= sessIdLen; memcpy(data.session_id, sessId, sessIdLen); CRYPTO_r_lock(CRYPTO_LOCK_SSL_CTX); ret= (SSL_SESSION *)lh_retrieve((_LHASH *)sslCtx->sessions, &data); CRYPTO_r_unlock(CRYPTO_LOCK_SSL_CTX); Thanks and Regards, Sunil Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.cudbardb at freeradius.org Fri Oct 22 13:55:24 2021 From: a.cudbardb at freeradius.org (Arran Cudbard-Bell) Date: Fri, 22 Oct 2021 09:55:24 -0400 Subject: Use of ossl_unused in err.h.in In-Reply-To: <75a3ee45-a533-56ac-9de7-e1aff3f86e09@openssl.org> References: <6FDEA5D3-4869-4AF1-8EA0-D714D0EAB205@freeradius.org> <75a3ee45-a533-56ac-9de7-e1aff3f86e09@openssl.org> Message-ID: > On Oct 4, 2021, at 3:00 AM, Matt Caswell wrote: > > Please raise a github issue for this. https://github.com/openssl/openssl/issues/16776 Raised but there's no resolution. I don't think there's much value in suggesting additional fixes for this problem, as the reasons for it existing are poorly defined, as are the reasons for rejecting my initial suggestions. If you guys could come up with a fix internally that didn't involve generating spurious warnings any time these functions are called from application code, it'd be much appreciated. -Arran -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From kgoldman at us.ibm.com Fri Oct 22 20:02:56 2021 From: kgoldman at us.ibm.com (Ken Goldman) Date: Fri, 22 Oct 2021 16:02:56 -0400 Subject: Openssl 3.0.0 creating ECC key from X and Y, PEM_write_PUBKEY fails Message-ID: I have X and Y as bignums. I create EVP_PKEY with this. I suspect that I have to do another step to indicate that I supplied X and Y and not a compressed public key. param_bld = OSSL_PARAM_BLD_new(); rc = getEcCurveString(&curveString, gets strings like prime256v1 irc = OSSL_PARAM_BLD_push_utf8_string(param_bld, OSSL_PKEY_PARAM_GROUP_NAME, curveString, 0); irc = OSSL_PARAM_BLD_push_BN(param_bld, OSSL_PKEY_PARAM_EC_PUB_X, x); irc = OSSL_PARAM_BLD_push_BN(param_bld, OSSL_PKEY_PARAM_EC_PUB_Y, y); params = OSSL_PARAM_BLD_to_param(param_bld); ctx = EVP_PKEY_CTX_new_from_name(NULL, "EC", NULL); irc = EVP_PKEY_fromdata_init(ctx); irc = EVP_PKEY_fromdata(ctx, evpPubkey, EVP_PKEY_PUBLIC_KEY, params); following that, this fails with irc = PEM_write_PUBKEY(pemFile, evpPubkey); ==88032== Invalid read of size 8 +=88032== at 0x4CB27F7: ec_point_is_compat (ec_local.h:328) ==88032== by 0x4CB2AB1: EC_POINT_point2oct (ec_oct.c:82) ==88032== by 0x4CA506F: i2o_ECPublicKey (ec_asn1.c:1158) ==88032== by 0x4E7B0D2: ec_spki_pub_to_der (encode_key2any.c:701) ==88032== by 0x4E79DBE: key_to_pubkey (encode_key2any.c:154) ==88032== by 0x4E7A490: key_to_spki_pem_pub_bio (encode_key2any.c:348) ==88032== by 0x4E7B9CA: key2any_encode (encode_key2any.c:1043) ==88032== by 0x4E7F539: ec_to_SubjectPublicKeyInfo_pem_encode (encode_key2any.c:1359) ==88032== by 0x4CF2C3F: encoder_process (encoder_lib.c:632) ==88032== by 0x4CF17AC: OSSL_ENCODER_to_bio (encoder_lib.c:63) ==88032== by 0x4CF1897: OSSL_ENCODER_to_fp (encoder_lib.c:85) ==88032== by 0x4D8BE33: PEM_write_PUBKEY (pem_all.c:226) point is null From alex.dankow at gmail.com Sat Oct 23 04:04:39 2021 From: alex.dankow at gmail.com (Alex Dankow) Date: Sat, 23 Oct 2021 11:04:39 +0700 Subject: Matching keys between providers Message-ID: Hi OpenSSL users and its glorious developers, Thank you very much for OpenSSL 3! My question is about writing a provider. I decided to start from a Windows certificate storage provider. It already works with "openssl storeutl" command, but can't make it work with "openssl ca". When openssl expects a certificate, I return an encoded certificate directly. OpenSSL parses it and the public key belongs to the "OpenSSL RSA" provider. I can't give private keys from Windows cert. storage and return something virtual from my key management provider. At the next step, openssl.exe does matching, compares key types: public key's type is "OpenSSL RSA" and the private key type of "MYPKEY". It is done in evp_keymgmt_util_match. I was hoping it would be called OSSL_FUNC_KEYMGMT_MATCH for both providers, but it only compares strings and says types are different. If I declare that my key management also handles RSA in OSSL_ALGORITHM as "MYPKEY:RSA" OpenSSL tool gives an error that RSA has an existing different identity. I'm exploring the source, but I'm stuck. Is it the wrong approach or I missed something ? -- Best Regards Alex Dankow -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetson23 at hotmail.com Sat Oct 23 16:58:43 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Sat, 23 Oct 2021 16:58:43 +0000 Subject: OpenSSL 3.0 FIPS questions Message-ID: Quick aside: I know the 3.0 FIPS module is not "approved" yet, I'm just trying to get my application updates done in advance. I?m porting an application from OpenSSL 1.1.1, which was originally written for OpenSSL 1.0.2, to OpenSSL 3.0. Going to 3.0, I need to incorporate FIPS usage. My Linux application basically is told if its user wants to use FIPS or not. We don?t use the cryptographic APIs (EVP_*), we just need to create an SSL_CTX, and SSL objects created with SSL_new() based on this SSL_CTX, which will then call SSL_read(), SSL_write(), etc. The application won?t ?fetch? any algorithms. So my focus can been on Section 7.7 of the Wiki: https://wiki.openssl.org/index.php/OpenSSL_3.0#Using_the_FIPS_module_in_SSL.2FTLS Based on if FIPS is on or off, I will use the replacement for SSL_CTX_new() and call SSL_CTX_new_ex() either something like this: ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); or this: ctx = SSL_CTX_new_ex(fips_libctx, NULL, TLS_method()); Depending on if the users does not want FIPS, or wants FIPS, respectively. Based on that and what Section 7.7 tells me, I know I need: 1. A non-default library context with the FIPS provider loaded (called fips_libctx), and 2. A non-default library context with the default provider loaded (called non_fips_libctx) I know that I don?t want all applications using OpenSSL to use the FIPS module by default, so I?m just trying to configure mine correctly, using the APIs (and possibly config files). I also obviously don?t want to make my application use the FIPS module only. Given all of the above I?m confused on how to set up #1 and #2. It seems like I need to use a combination of configuration files and programmatically calling APIs in my application. In the Wiki and the fips_module man page there is a section called ?Programmatically loading the FIPS module (nondefault library context)?. I?m pretty sure this is what I want. The code example says it ?assumes the existence of a config file called openssl-fips.cnf that automatically loads and configures the FIPS and base providers.? The .cnf files that I have after the (FIPS) install of OpenSSL 3.0 are in /usr/local/ssl/: openssl.cnf and fipsmodule.cnf. I guess the first thing is I?m confused on if the ?openssl-fips.cnf? file referred to in the example is in addition to the two files above, or a replacement for one of them, and also what the contents of it need to be. I had already made changes to the openssl.cnf file for FIPS (described in earlier sections of the Wiki): # For FIPS # Optionally include a file that is generated by the OpenSSL fipsinstall # application. This file contains configuration data required by the OpenSSL # fips provider. It contains a named section e.g. [fips_sect] which is # referenced from the [provider_sect] below. # Refer to the OpenSSL security policy for more information. .include /usr/local/ssl/fipsmodule.cnf ? uncommented [openssl_init] providers = provider_sect # List of providers to load [provider_sect] default = default_sect # The fips section name should match the section name inside the # included fipsmodule.cnf. fips = fips_sect ? uncommented # If no providers are activated explicitly, the default one is activated implicitly. # See man 7 OSSL_PROVIDER-default for more details. # # If you add a section explicitly activating any other provider(s), you most # probably need to explicitly activate the default provider, otherwise it # becomes unavailable in openssl. As a consequence applications depending on # OpenSSL may not work correctly which could lead to significant system # problems including inability to remotely access the system. [default_sect] activate = 1 ? uncommented I did this to make sure the FIPS provider was available and make sure the default provider was activated. I also changed the fipsmodule.cnf file to comment out the activate = 1 line: [fips_sect] # activate = 1 conditional-errors = 1 security-checks = 1 module-mac = E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9 That was from the ?Programmatically loading the FIPS module (default library context)? section, so I?m wondering if this was a mistake. But currently, with the configs files as described above, my application is loading both providers: fipsp = OSSL_PROVIDER_load(NULL, "fips"); if (fipsp == NULL) { /* error handling */ } defp = OSSL_PROVIDER_load(NULL, "default"); if (defp == NULL) { /* error handling */ } And then creating two library contexts: fips_libctx = OSSL_LIB_CTX_new(); non_fips_libctx = OSSL_LIB_CTX_new(); Which are later used to create SSL_CTX?s as needed: if (user does not want fips) { ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); } else (user wants fips) { ctx = SSL_CTX_new_ex(fips_libctx, NULL, TLS_method()); } But I think the 2nd to last step is probably creating two library contexts, both using fips because of my changes to the default configuration file. (more on my changes to the default file later) Looking at section 7.5 of the Wiki, I?m thinking I need to create a file called openssl-fips.cnf with the contents something like(or maybe a minimum of): [fips_sect] activate = 1 conditional-errors = 1 security-checks = 1 module-mac = E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9 [base_sect] activate = 1 Then before creating SSL_CTX?s and after the OSSL_LIB_CTX() calls, I need to call: OSSL_LIB_CTX_load_config(fips_libctx, ?openssl-fips.cnf?); Which will get the FIPS and base providers in the fips_libctx. The non_fips_libctx will use the default config file and have the default provider, which is what I want. Also, it seems like I need to call: defctxnull = OSSL_PROVIDER_load(NULL, ?null?); Which is to ?prevent anything from using the default library context?? Also, I probably need to revert my changes to the default config file to not activate additional providers, which means only the default one will be activate implicitly. Then the non_fips_libctx = OSSL_LIB_CTX_new(); line will set up the default provider in non_fips_libctx. I?m hoping someone can point me in the right direction, because the other problem is that I?m not sure how to validate what I?ve done is correct. As in, how do I know fips_libctx is actually ?FIPS? compliant, and/or the SSL_CTX?s I create are ?FIPS?. I realize there are probably several ways to do this, but I?m looking to isolate my application only this way, and not affect any other applications on the system. Thanks in advance. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From kory at avatarci.com Sat Oct 23 17:15:05 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Sat, 23 Oct 2021 10:15:05 -0700 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: Message-ID: <12C60253-C1B9-436B-80A9-35091192E5D2@avatarci.com> One way to do what you want is with two config file, and and in the first line of your main() function, add: putenv(?OPENSSL_CONF=/path/to/your/conf?) depending on whether you want to run in FIPS mode or not. Of course, this only works if FIPS is needed application wide, not on a per connection basis. If running in FIPS mode, I would also call: EVP_set_default_properties(NULL, ?fips=yes?); > On Oct 23, 2021, at 9:58 AM, Jason Schultz wrote: > > Quick aside: I know the 3.0 FIPS module is not "approved" yet, I'm just trying to get my application updates done in advance. > > I?m porting an application from OpenSSL 1.1.1, which was originally written for OpenSSL 1.0.2, to OpenSSL 3.0. Going to 3.0, I need to incorporate FIPS usage. My Linux application basically is told if its user wants to use FIPS or not. We don?t use the cryptographic APIs (EVP_*), we just need to create an SSL_CTX, and SSL objects created with SSL_new() based on this SSL_CTX, which will then call SSL_read(), SSL_write(), etc. The application won?t ?fetch? any algorithms. So my focus can been on Section 7.7 of the Wiki: > > https://wiki.openssl.org/index.php/OpenSSL_3.0#Using_the_FIPS_module_in_SSL.2FTLS > > Based on if FIPS is on or off, I will use the replacement for SSL_CTX_new() and call SSL_CTX_new_ex() either something like this: > > ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); > > or this: > > ctx = SSL_CTX_new_ex(fips_libctx, NULL, TLS_method()); > > Depending on if the users does not want FIPS, or wants FIPS, respectively. > > Based on that and what Section 7.7 tells me, I know I need: > > A non-default library context with the FIPS provider loaded (called fips_libctx), and > A non-default library context with the default provider loaded (called non_fips_libctx) > > I know that I don?t want all applications using OpenSSL to use the FIPS module by default, so I?m just trying to configure mine correctly, using the APIs (and possibly config files). I also obviously don?t want to make my application use the FIPS module only. > > Given all of the above I?m confused on how to set up #1 and #2. It seems like I need to use a combination of configuration files and programmatically calling APIs in my application. In the Wiki and the fips_module man page there is a section called ?Programmatically loading the FIPS module (nondefault library context)?. I?m pretty sure this is what I want. The code example says it ?assumes the existence of a config file called openssl-fips.cnf that automatically loads and configures the FIPS and base providers.? > > The .cnf files that I have after the (FIPS) install of OpenSSL 3.0 are in /usr/local/ssl/: openssl.cnf and fipsmodule.cnf. > > I guess the first thing is I?m confused on if the ?openssl-fips.cnf? file referred to in the example is in addition to the two files above, or a replacement for one of them, and also what the contents of it need to be. > > I had already made changes to the openssl.cnf file for FIPS (described in earlier sections of the Wiki): > > # For FIPS > # Optionally include a file that is generated by the OpenSSL fipsinstall > # application. This file contains configuration data required by the OpenSSL > # fips provider. It contains a named section e.g. [fips_sect] which is > # referenced from the [provider_sect] below. > # Refer to the OpenSSL security policy for more information. > .include /usr/local/ssl/fipsmodule.cnf ? uncommented > > [openssl_init] > providers = provider_sect > > # List of providers to load > [provider_sect] > default = default_sect > # The fips section name should match the section name inside the > # included fipsmodule.cnf. > fips = fips_sect ? uncommented > > # If no providers are activated explicitly, the default one is activated implicitly. > # See man 7 OSSL_PROVIDER-default for more details. > # > # If you add a section explicitly activating any other provider(s), you most > # probably need to explicitly activate the default provider, otherwise it > # becomes unavailable in openssl. As a consequence applications depending on > # OpenSSL may not work correctly which could lead to significant system > # problems including inability to remotely access the system. > [default_sect] > activate = 1 ? uncommented > > I did this to make sure the FIPS provider was available and make sure the default provider was activated. > > I also changed the fipsmodule.cnf file to comment out the activate = 1 line: > > [fips_sect] > # activate = 1 > conditional-errors = 1 > security-checks = 1 > module-mac = E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9 > > That was from the ?Programmatically loading the FIPS module (default library context)? section, so I?m wondering if this was a mistake. > > But currently, with the configs files as described above, my application is loading both providers: > > fipsp = OSSL_PROVIDER_load(NULL, "fips"); > if (fipsp == NULL) > { > /* error handling */ > } > > defp = OSSL_PROVIDER_load(NULL, "default"); > if (defp == NULL) > { > /* error handling */ > } > > And then creating two library contexts: > > fips_libctx = OSSL_LIB_CTX_new(); > non_fips_libctx = OSSL_LIB_CTX_new(); > > Which are later used to create SSL_CTX?s as needed: > > if (user does not want fips) > { > ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); > } > else (user wants fips) > { > ctx = SSL_CTX_new_ex(fips_libctx, NULL, TLS_method()); > } > > But I think the 2nd to last step is probably creating two library contexts, both using fips because of my changes to the default configuration file. (more on my changes to the default file later) Looking at section 7.5 of the Wiki, I?m thinking I need to create a file called openssl-fips.cnf with the contents something like(or maybe a minimum of): > > [fips_sect] > activate = 1 > conditional-errors = 1 > security-checks = 1 > module-mac = E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9 > [base_sect] > activate = 1 > > Then before creating SSL_CTX?s and after the OSSL_LIB_CTX() calls, I need to call: > > OSSL_LIB_CTX_load_config(fips_libctx, ?openssl-fips.cnf?); > > Which will get the FIPS and base providers in the fips_libctx. The non_fips_libctx will use the default config file and have the default provider, which is what I want. > > Also, it seems like I need to call: > > defctxnull = OSSL_PROVIDER_load(NULL, ?null?); > > Which is to ?prevent anything from using the default library context?? > > Also, I probably need to revert my changes to the default config file to not activate additional providers, which means only the default one will be activate implicitly. Then the non_fips_libctx = OSSL_LIB_CTX_new(); line will set up the default provider in non_fips_libctx. > > I?m hoping someone can point me in the right direction, because the other problem is that I?m not sure how to validate what I?ve done is correct. As in, how do I know fips_libctx is actually ?FIPS? compliant, and/or the SSL_CTX?s I create are ?FIPS?. I realize there are probably several ways to do this, but I?m looking to isolate my application only this way, and not affect any other applications on the system. > > Thanks in advance. > > Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Sun Oct 24 00:06:36 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Sun, 24 Oct 2021 10:06:36 +1000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: Message-ID: There are several approaches you could take.? With two library contexts: fips_libctx = OSSL_LIB_CTX_new(); non_fips_libctx = OSSL_LIB_CTX_new(); fipsp = OSSL_PROVIDER_load(fips_libctx, "fips"); basep = OSSL_PROVIDER_load(fips_libctx,"base");? /* can't load keys without this */ defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); nullp = OSSL_PROVIDER_load(NULL, "null");?? ? ? /* Disallow falling back to the default library context */ Then use either fips_libctx or non_fips_libctx for operations. Alternatively, it can be done in one library context (the default here), although there is some risk of using non-FIPS crypto in a FIPS context: fipsp = OSSL_PROVIDER_load(NULL, "fips"); defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); For FIPS, make sure that "fips=yes" is included as a property query.? The easiest way is to do this globally: EVP_set_default_properties(NULL, ?fips=yes?); For non-FIPS, just don't do anything. Personally, I'd do the former two library contexts based approach and not worry about the properties. Pauli On 24/10/21 2:58 am, Jason Schultz wrote: > > Quick aside: I know the 3.0 FIPS module is not "approved" yet, I'm > just trying to get my application updates done in advance. > > > I?m porting an application from OpenSSL 1.1.1, which was originally > written for OpenSSL 1.0.2, to OpenSSL 3.0. Going to 3.0, I need to > incorporate FIPS usage. My Linux application basically is told if its > user wants to use FIPS or not. We don?t use the cryptographic APIs > (EVP_*), we just need to create an SSL_CTX, and SSL objects created > with SSL_new() based on this SSL_CTX, which will then call SSL_read(), > SSL_write(), etc. The application won?t ?fetch? any algorithms. So my > focus can been on Section 7.7 of the Wiki: > > https://wiki.openssl.org/index.php/OpenSSL_3.0#Using_the_FIPS_module_in_SSL.2FTLS > > Based on if FIPS is on or off, I will use the replacement for > SSL_CTX_new() and call SSL_CTX_new_ex() either something like this: > > ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); > > or this: > > ctx = SSL_CTX_new_ex(fips_libctx, NULL, TLS_method()); > > Depending on if the users does not want FIPS, or wants FIPS, > respectively. > > Based on that and what Section 7.7 tells me, I know I need: > > 1. A non-default library context with the FIPS provider loaded > (called fips_libctx), and > 2. A non-default library context with the default provider loaded > (called non_fips_libctx) > > I know that I don?t want all applications using OpenSSL to use the > FIPS module by default, so I?m just trying to configure mine > correctly, using the APIs (and possibly config files). I also > obviously don?t want to make my application use the FIPS module only. > > Given all of the above I?m confused on how to set up #1 and #2. It > seems like I need to use a combination of configuration files and > programmatically calling APIs in my application. In the Wiki and the > fips_module man page there is a section called ?Programmatically > loading the FIPS module (nondefault library context)?. I?m pretty sure > this is what I want. The code example says it ?assumes the existence > of a config file called openssl-fips.cnf that automatically loads and > configures the FIPS and base providers.? > > The .cnf files that I have after the (FIPS) install of OpenSSL 3.0 are > in /usr/local/ssl/: openssl.cnf and fipsmodule.cnf. > > I guess the first thing is I?m confused on if the ?openssl-fips.cnf? > file referred to in the example is in addition to the two files above, > or a replacement for one of them, and also what the contents of it > need to be. > > I had already made changes to the openssl.cnf file for FIPS (described > in earlier sections of the Wiki): > > # For FIPS > > # Optionally include a file that is generated by the OpenSSL fipsinstall > > # application. This file contains configuration data required by the > OpenSSL > > # fips provider. It contains a named section e.g. [fips_sect] which is > > # referenced from the [provider_sect] below. > > # Refer to the OpenSSL security policy for more information. > > .include */usr/local/ssl/fipsmodule.cnf****?***uncommented > > [openssl_init] > > providers = provider_sect > > # List of providers to load > > [provider_sect] > > default = default_sect > > # The fips section name should match the section name inside the > > # included fipsmodule.cnf. > > fips = fips_sect?uncommented > > # If no providers are activated explicitly, the default one is > activated implicitly. > > # See man 7 OSSL_PROVIDER-default for more details. > > # > > # If you add a section explicitly activating any other provider(s), > you most > > # probably need to explicitly activate the default provider, otherwise it > > # becomes unavailable in openssl.As a consequence applications > depending on > > # OpenSSL may not work correctly which could lead to significant system > > # problems including inability to remotely access the system. > > [default_sect] > > activate = 1?uncommented > > I did this to make sure the FIPS provider was available and make sure > the default provider was activated. > > I also changed the fipsmodule.cnf file to comment out the activate = 1 > line: > > [fips_sect] > > # activate = 1 > > conditional-errors = 1 > > security-checks = 1 > > module-mac = > E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9 > > That was from the ?Programmatically loading the FIPS module (default > library context)? section, so I?m wondering if this was a mistake. > > But currently, with the configs files as described above, my > application is loading both providers: > > fipsp = OSSL_PROVIDER_load(NULL, "fips"); > > if (fipsp == NULL) > > { > > /* error handling */ > > } > > defp = OSSL_PROVIDER_load(NULL, "default"); > > if (defp == NULL) > > { > > /* error handling */ > > } > > And then creating two library contexts: > > fips_libctx = OSSL_LIB_CTX_new(); > > non_fips_libctx = OSSL_LIB_CTX_new(); > > Which are later used to create SSL_CTX?s as needed: > > if (user does not want fips) > > { > > ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); > > } > > else (user wants fips) > > { > > ctx = SSL_CTX_new_ex(fips_libctx, NULL, TLS_method()); > > } > > But I think the 2^nd to last step is probably creating two library > contexts, both using fips because of my changes to the default > configuration file. (more on my changes to the default file later) > Looking at section 7.5 of the Wiki, I?m thinking I need to create a > file called openssl-fips.cnf with the contents something like(or maybe > a minimum of): > > [fips_sect] > > activate = 1 > > conditional-errors = 1 > > security-checks = 1 > > module-mac = > E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9 > > [base_sect] > > activate = 1 > > Then before creating SSL_CTX?s and after the OSSL_LIB_CTX() calls, I > need to call: > > OSSL_LIB_CTX_load_config(fips_libctx, ?openssl-fips.cnf?); > > Which will get the FIPS and base providers in the fips_libctx. The > non_fips_libctx will use the default config file and have the default > provider, which is what I want. > > Also, it seems like I need to call: > > defctxnull = OSSL_PROVIDER_load(NULL, ?null?); > > Which is to ?prevent anything from using the default library context?? > > Also, I probably need to revert my changes to the default config file > to not activate additional providers, which means only the default one > will be activate implicitly. Then the non_fips_libctx = > OSSL_LIB_CTX_new(); line will set up the default provider in > non_fips_libctx. > > I?m hoping someone can point me in the right direction, because the > other problem is that I?m not sure how to validate what I?ve done is > correct. As in, how do I know fips_libctx is actually ?FIPS? > compliant, and/or the SSL_CTX?s I create are ?FIPS?. I realize there > are probably several ways to do this, but I?m looking to isolate my > application only this way, and not affect any other applications on > the system. > > Thanks in advance. > > > Jason > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Sun Oct 24 00:28:32 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Sun, 24 Oct 2021 10:28:32 +1000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: Message-ID: Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");" Pauli On 24/10/21 10:06 am, Dr Paul Dale wrote: > defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetson23 at hotmail.com Sun Oct 24 19:23:34 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Sun, 24 Oct 2021 19:23:34 +0000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: Message-ID: Thank you for your response. I think all of that makes sense, and seems to accomplish what I want programmatically, limiting it to my application. I guess the only question I have is what about the config files? Should they remain as they were installed, or do I need to provide sections for fips, base, default, etc? Regards, Jason ________________________________ From: openssl-users on behalf of Dr Paul Dale Sent: Sunday, October 24, 2021 12:28 AM To: openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");" Pauli On 24/10/21 10:06 am, Dr Paul Dale wrote: defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Sun Oct 24 23:12:18 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Mon, 25 Oct 2021 09:12:18 +1000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: Message-ID: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> The configuration shouldn't have much impact.? You will need a fips section specifying where the integrity check data are.? You shouldn't need base or default sections. Pauli On 25/10/21 5:23 am, Jason Schultz wrote: > Thank you for your response. I think all of that makes?sense, and > seems to accomplish what I want programmatically, limiting it to my > application. I guess the only question I have is what about the config > files? Should they remain as they were installed, or do I need to > provide sections for fips, base, default, etc? > > Regards, > > Jason > > > ------------------------------------------------------------------------ > *From:* openssl-users on behalf of > Dr Paul Dale > *Sent:* Sunday, October 24, 2021 12:28 AM > *To:* openssl-users at openssl.org > *Subject:* Re: OpenSSL 3.0 FIPS questions > Oops, the second time this occurs "defp = > OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = > OSSL_PROVIDER_load(NULL, "default");" > > > Pauli > > On 24/10/21 10:06 am, Dr Paul Dale wrote: >> defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sunil.Paramashivaiah at rbbn.com Mon Oct 25 04:45:17 2021 From: Sunil.Paramashivaiah at rbbn.com (Paramashivaiah, Sunil) Date: Mon, 25 Oct 2021 04:45:17 +0000 Subject: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 Message-ID: Hi All, I need get APIs for accessing the members of EVP_PKEY. Please suggest APIs to get following members of EVP_PKEY evpkey->type , evpkey->pkey.rsa , pubKey->pkey.ec->group. Thanks and Regards, Sunil Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Mon Oct 25 08:01:40 2021 From: tomas at openssl.org (Tomas Mraz) Date: Mon, 25 Oct 2021 10:01:40 +0200 Subject: Matching keys between providers In-Reply-To: References: Message-ID: On Sat, 2021-10-23 at 11:04 +0700, Alex Dankow wrote: > Hi OpenSSL users and its glorious developers, > > Thank you very much for OpenSSL 3! > > My question is about writing a provider. I decided to start from a > Windows certificate storage provider. It already works with "openssl > storeutl" command, but can't make it work with "openssl ca". > > When openssl expects a certificate, I return an encoded certificate > directly. OpenSSL parses it and the public key belongs to the "OpenSSL > RSA" provider. I can't give private keys from Windows cert. storage and > return something virtual from my key management provider. > > At the next step, openssl.exe does matching, compares key types: public > key's type is "OpenSSL RSA" and the private key type of "MYPKEY". It is > done in? evp_keymgmt_util_match. > I was hoping it would be called OSSL_FUNC_KEYMGMT_MATCH for both > providers, but it only compares strings and says types are different. > If I declare that my key management also handles RSA in OSSL_ALGORITHM > as "MYPKEY:RSA" OpenSSL tool gives an error that RSA has an existing > different identity. > > I'm exploring the source, but I'm stuck. Is it the wrong approach or I > missed something ? This is something that should be resolved by: https://github.com/openssl/openssl/pull/16725 The key type for RSA keys must be "RSA". And the PR linked above should ensure that the unexportable RSA keys from the keystore would be handled by your provider. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. ??????????????????????????????????????????????Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From matt at openssl.org Mon Oct 25 08:53:14 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 25 Oct 2021 09:53:14 +0100 Subject: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 In-Reply-To: References: Message-ID: <3b8d168c-eeb2-0813-6721-1c544c4599c4@openssl.org> On 25/10/2021 05:45, Paramashivaiah, Sunil wrote: > Hi All, > > ??????? I need get APIs for accessing the members of? EVP_PKEY. Please > suggest APIs to get following members of EVP_PKEY > > evpkey->type , evpkey->pkey.rsa , pubKey->pkey.ec->group. EVP_PKEY_get_id() will get you the `evpkey->type` value. But note that in the provider world an external provider could add key types that are unknown to libcrypto. "EVP_PKEY_is_a" is a more future proof way to go. https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_is_a.html E.g. if (EVP_PKEY_is_a(pkey, "RSA")) ...; if (EVP_PKEY_is_a(pkey, "EC")) ...; The "evppkey->pkey.rsa" value can be obtained via EVP_PKEY_get0_RSA() but note that this is deprecated. You are encouraged to not use the RSA structure at all in 3.0 (all the functions that take an RSA structure are deprecated). So you should look at what you are trying to do with evpkey->pkey.rsa and refactor things to not need it. Why do you want this? Similar comments apply to "pubkey->pkey.ec". You can get the EC_KEY object using EVP_PKEY_get0_EC_KEY() but this is deprecated. You can get the group from an EC_KEY using EC_KEY_get0_group() - but this is also deprecated. Instead you might consider getting the "group name" for the EC key which will tell you what curve is in use, e.g. EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, NULL, 0, &namesize); name = OPENSSL_malloc(namesize + 1); EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, name, namesize + 1, 0); https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_get_utf8_string_param.html Matt > > Thanks and Regards, > > Sunil > > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others or > forwarding without express permission is strictly prohibited. If you are > not the intended recipient, please notify the sender immediately and > then delete all copies, including any attachments. From Sunil.Paramashivaiah at rbbn.com Mon Oct 25 09:21:27 2021 From: Sunil.Paramashivaiah at rbbn.com (Paramashivaiah, Sunil) Date: Mon, 25 Oct 2021 09:21:27 +0000 Subject: [EXTERNAL] Re: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 In-Reply-To: <3b8d168c-eeb2-0813-6721-1c544c4599c4@openssl.org> References: <3b8d168c-eeb2-0813-6721-1c544c4599c4@openssl.org> Message-ID: Hi Matt, Thanks for the reply. I need to replace the below code. int keysz,ecGrpId; switch(evpKey->type) { case NID_rsaEncryption: { if(evpKey->pkey.rsa) { keysz = BN_num_bits(evpKey->pkey.rsa->n); . . /* some code */ } break; } case NID_X9_62_id_ecPublicKey: { ecGrpId = EC_GROUP_get_curve_name(evpKey->pkey.ec->group); /* some code follows*/ Thanks and Regards, Sunil -----Original Message----- From: Matt Caswell Sent: Monday, October 25, 2021 2:23 PM To: Paramashivaiah, Sunil ; openssl-users at openssl.org Subject: [EXTERNAL] Re: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 On 25/10/2021 05:45, Paramashivaiah, Sunil wrote: > Hi All, > > ??????? I need get APIs for accessing the members of? EVP_PKEY. > Please suggest APIs to get following members of EVP_PKEY > > evpkey->type , evpkey->pkey.rsa , pubKey->pkey.ec->group. EVP_PKEY_get_id() will get you the `evpkey->type` value. But note that in the provider world an external provider could add key types that are unknown to libcrypto. "EVP_PKEY_is_a" is a more future proof way to go. https://clicktime.symantec.com/3TPr6AZe5xYBkrduooQtHHv6H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FEVP_PKEY_is_a.html E.g. if (EVP_PKEY_is_a(pkey, "RSA")) ...; if (EVP_PKEY_is_a(pkey, "EC")) ...; The "evppkey->pkey.rsa" value can be obtained via EVP_PKEY_get0_RSA() but note that this is deprecated. You are encouraged to not use the RSA structure at all in 3.0 (all the functions that take an RSA structure are deprecated). So you should look at what you are trying to do with evpkey->pkey.rsa and refactor things to not need it. Why do you want this? Similar comments apply to "pubkey->pkey.ec". You can get the EC_KEY object using EVP_PKEY_get0_EC_KEY() but this is deprecated. You can get the group from an EC_KEY using EC_KEY_get0_group() - but this is also deprecated. Instead you might consider getting the "group name" for the EC key which will tell you what curve is in use, e.g. EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, NULL, 0, &namesize); name = OPENSSL_malloc(namesize + 1); EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, name, namesize + 1, 0); https://clicktime.symantec.com/36qEeyKryNCZ32uxNgfFe4p6H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FEVP_PKEY_get_utf8_string_param.html Matt > > Thanks and Regards, > > Sunil > > > Notice: This e-mail together with any attachments may contain > information of Ribbon Communications Inc. and its Affiliates that is > confidential and/or proprietary for the sole use of the intended > recipient. Any review, disclosure, reliance or distribution by others > or forwarding without express permission is strictly prohibited. If > you are not the intended recipient, please notify the sender > immediately and then delete all copies, including any attachments. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. From matt at openssl.org Mon Oct 25 09:33:16 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 25 Oct 2021 10:33:16 +0100 Subject: [EXTERNAL] Re: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 In-Reply-To: References: <3b8d168c-eeb2-0813-6721-1c544c4599c4@openssl.org> Message-ID: <1963a297-94af-5638-4678-97c312485a7f@openssl.org> Caveat: I've not tested or compiled the following...but something like this: if (EVP_PKEY_is_a(evpKey, "RSA)) { keysz = EVP_PKEY_get_bits(evpKey) / 8; /* some code */ } else if (EVP_PKEY_is_a(evpKey, "EC")) { char *name; size_t namesize; if (!EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, NULL, 0, &namesize)) /* error */; name = OPENSSL_malloc(namesize + 1); if (name == NULL) /* error */ if (!EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, name, namesize + 1, 0)) /* error */ /* This gets you the curve name as a string. If you really need as * an integer you can additionally do the following - but note that * some providers might add curves that libcrypto doesn't know about * so this could fail */ ecGrpId = OBJ_txt2nid(name); if (ecGrpId == NID_undef) /* error */; OPENSSL_free(name); /* some code */ } On 25/10/2021 10:21, Paramashivaiah, Sunil wrote: > Hi Matt, > > Thanks for the reply. I need to replace the below code. > > int keysz,ecGrpId; > > switch(evpKey->type) > { > case NID_rsaEncryption: > { > if(evpKey->pkey.rsa) > { > keysz = BN_num_bits(evpKey->pkey.rsa->n); > . > . > /* some code */ > } > break; > } > case NID_X9_62_id_ecPublicKey: > { > ecGrpId = EC_GROUP_get_curve_name(evpKey->pkey.ec->group); > /* some code follows*/ > > Thanks and Regards, > Sunil > > -----Original Message----- > From: Matt Caswell > Sent: Monday, October 25, 2021 2:23 PM > To: Paramashivaiah, Sunil ; openssl-users at openssl.org > Subject: [EXTERNAL] Re: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 > > > > On 25/10/2021 05:45, Paramashivaiah, Sunil wrote: >> Hi All, >> >> ??????? I need get APIs for accessing the members of? EVP_PKEY. >> Please suggest APIs to get following members of EVP_PKEY >> >> evpkey->type , evpkey->pkey.rsa , pubKey->pkey.ec->group. > > EVP_PKEY_get_id() will get you the `evpkey->type` value. But note that in the provider world an external provider could add key types that are unknown to libcrypto. "EVP_PKEY_is_a" is a more future proof way to go. > > https://clicktime.symantec.com/3TPr6AZe5xYBkrduooQtHHv6H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FEVP_PKEY_is_a.html > > E.g. > > if (EVP_PKEY_is_a(pkey, "RSA")) ...; > if (EVP_PKEY_is_a(pkey, "EC")) ...; > > > The "evppkey->pkey.rsa" value can be obtained via EVP_PKEY_get0_RSA() but note that this is deprecated. You are encouraged to not use the RSA structure at all in 3.0 (all the functions that take an RSA structure are deprecated). So you should look at what you are trying to do with > evpkey->pkey.rsa and refactor things to not need it. Why do you want this? > > Similar comments apply to "pubkey->pkey.ec". You can get the EC_KEY object using EVP_PKEY_get0_EC_KEY() but this is deprecated. You can get the group from an EC_KEY using EC_KEY_get0_group() - but this is also deprecated. Instead you might consider getting the "group name" for the EC key which will tell you what curve is in use, e.g. > > EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, > NULL, 0, &namesize); name = OPENSSL_malloc(namesize + 1); EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, > name, namesize + 1, 0); > > https://clicktime.symantec.com/36qEeyKryNCZ32uxNgfFe4p6H2?u=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FEVP_PKEY_get_utf8_string_param.html > > Matt > > >> >> Thanks and Regards, >> >> Sunil >> >> >> Notice: This e-mail together with any attachments may contain >> information of Ribbon Communications Inc. and its Affiliates that is >> confidential and/or proprietary for the sole use of the intended >> recipient. Any review, disclosure, reliance or distribution by others >> or forwarding without express permission is strictly prohibited. If >> you are not the intended recipient, please notify the sender >> immediately and then delete all copies, including any attachments. > > Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. > From alex.dankow at gmail.com Mon Oct 25 09:51:25 2021 From: alex.dankow at gmail.com (Alex Dankow) Date: Mon, 25 Oct 2021 16:51:25 +0700 Subject: OSSL_DECODER_CTX_new_for_pkey can't find decoder Message-ID: Hi everyone, I'm writing a provider for Windows certificates. It generally works like this openssl x509 -in "myuri ......" -provider mytest -text OpenSSL fetches a DER encoded certificate from my STORE and prints it. However it doesn't print the public key itself. The code in x_pubkey.c near OSSL_DECODER_CTX_new_for_pkey "DER", "SubjectPublicKeyInfo" fails to find a decoder. The rest is decoded by OpenSSL But if I add provider "default" in the command line: openssl x509 -in "myuri ......" -provider mytest -provider default -text It works completely. Am I missing something or is it a bug ? -- Best Regards Alex Dankow -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Oct 25 10:02:20 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 25 Oct 2021 11:02:20 +0100 Subject: OSSL_DECODER_CTX_new_for_pkey can't find decoder In-Reply-To: References: Message-ID: <80055ca0-5035-8c8a-95a5-da877e5a21fa@openssl.org> On 25/10/2021 10:51, Alex Dankow wrote: > Hi everyone, > > I'm writing a provider for Windows certificates. > It generally works like this > > openssl x509 -in "myuri ......" -provider mytest -text > > OpenSSL fetches a DER encoded certificate from my STORE and prints it. > However it doesn't print the public key itself. > The code in x_pubkey.c near OSSL_DECODER_CTX_new_for_pkey "DER", > "SubjectPublicKeyInfo" fails to find a decoder. The rest is decoded by > OpenSSL > > But if I add provider "default" in the command line: > openssl x509 -in "myuri ......" -provider mytest -provider default -text > It works completely. > > Am I missing something or? is it a bug ? This is correct behaviour. From the crypto man page: 'If you don't load any providers at all then the "default" provider will be automatically loaded. If you explicitly load any provider then the "default" provider would also need to be explicitly loaded if it is required.' https://www.openssl.org/docs/man3.0/man7/crypto.html Also mentioned on the default provider man page: 'If an attempt to load a provider has already been made (whether successful or not) then the default provider won't be loaded automatically. Therefore if the default provider is to be used in conjunction with other providers then it must be loaded explicitly. Automatic loading of the default provider only occurs a maximum of once; if the default provider is explicitly unloaded then the default provider will not be automatically loaded again.' https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-default.html And on the config file man page: 'If no providers are activated explicitly, the default one is activated implicitly. See OSSL_PROVIDER-default(7) for more details. If you add a section explicitly activating any other provider(s), you most probably need to explicitly activate the default provider, otherwise it becomes unavailable in openssl. It may make the system remotely unavailable.' https://www.openssl.org/docs/man3.0/man5/config.html Matt From matt at openssl.org Mon Oct 25 14:05:14 2021 From: matt at openssl.org (Matt Caswell) Date: Mon, 25 Oct 2021 15:05:14 +0100 Subject: Openssl 3.0.0 creating ECC key from X and Y, PEM_write_PUBKEY fails In-Reply-To: References: Message-ID: On 22/10/2021 21:02, Ken Goldman wrote: > I have X and Y as bignums.? I create EVP_PKEY with this. > > I suspect that I have to do another step to indicate that I supplied X > and Y and not a compressed > public key. Unfortunately supplying x and y separately is not supported for import. You have to instead use OSSL_PKEY_PARAM_PUB_KEY. You can supply the key as an uncompressed public key simply be concatenating the byte "04", the x co-ord (padded to the appropriate size if necessary) and the y co-cord (also padded as appropriate). The OSSL_PKEY_PARAM_EC_PUB_X and OSSL_PKEY_PARAM_EC_PUB_Y parameters are defined as "getters" only. From the manual: "qx" (OSSL_PKEY_PARAM_EC_PUB_X) Used for getting the EC public key X component. "qy" (OSSL_PKEY_PARAM_EC_PUB_Y) Used for getting the EC public key Y component. https://www.openssl.org/docs/man3.0/man7/EVP_PKEY-EC.html > ????param_bld = OSSL_PARAM_BLD_new(); > ????rc = getEcCurveString(&curveString,??????? gets strings like > prime256v1 > ????irc = OSSL_PARAM_BLD_push_utf8_string(param_bld, > OSSL_PKEY_PARAM_GROUP_NAME, > ????????????????????????? curveString, 0); > ????irc = OSSL_PARAM_BLD_push_BN(param_bld, OSSL_PKEY_PARAM_EC_PUB_X, x); > ????irc = OSSL_PARAM_BLD_push_BN(param_bld, OSSL_PKEY_PARAM_EC_PUB_Y, y); > ????params = OSSL_PARAM_BLD_to_param(param_bld); > ????ctx = EVP_PKEY_CTX_new_from_name(NULL, "EC", NULL); > ????irc = EVP_PKEY_fromdata_init(ctx); > ????irc = EVP_PKEY_fromdata(ctx, evpPubkey, EVP_PKEY_PUBLIC_KEY, params); It's actually quite surprising that this call succeeds. IMO it should have failed: https://github.com/openssl/openssl/issues/16912 What you've actually ended up with here is a parameters only EVP_PKEY value. > > following that, this fails with > > ????irc = PEM_write_PUBKEY(pemFile, evpPubkey); > > ==88032== Invalid read of size 8 This crash is a bug in OpenSSL. You should have got a failure because your EVP_PKEY doesn't have a public key in it: https://github.com/openssl/openssl/pull/16911 Matt From jetson23 at hotmail.com Mon Oct 25 18:46:37 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Mon, 25 Oct 2021 18:46:37 +0000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> Message-ID: Thanks again. I think most of that makes sense. Going back to your initial response, there is something I'm not clear on. The second method you explained (which I don't plan to use) starting with "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then discussed calling the following API for FIPS: EVP_set_default_properties(NULL, ?fips=yes?); Was the EVP_set_default_properties() call specifically and only for the 2nd method, or did that API call apply to both the first and second methods you explained? From reading the doc for that call, it seems like I should be doing it if I use the first method as well. Regards, Jason ________________________________ From: openssl-users on behalf of Dr Paul Dale Sent: Sunday, October 24, 2021 11:12 PM To: openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions The configuration shouldn't have much impact. You will need a fips section specifying where the integrity check data are. You shouldn't need base or default sections. Pauli On 25/10/21 5:23 am, Jason Schultz wrote: Thank you for your response. I think all of that makes sense, and seems to accomplish what I want programmatically, limiting it to my application. I guess the only question I have is what about the config files? Should they remain as they were installed, or do I need to provide sections for fips, base, default, etc? Regards, Jason ________________________________ From: openssl-users on behalf of Dr Paul Dale Sent: Sunday, October 24, 2021 12:28 AM To: openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");" Pauli On 24/10/21 10:06 am, Dr Paul Dale wrote: defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); -------------- next part -------------- An HTML attachment was scrubbed... URL: From doa379 at gmail.com Mon Oct 25 20:45:38 2021 From: doa379 at gmail.com (doa379) Date: Mon, 25 Oct 2021 21:45:38 +0100 Subject: SSL handshake with a web server using Memory BIOs? Message-ID: Suppose the TLS layer is initialized in the form: SSL_CTX *ctx = SSL_CTX_new(TLS_client_method()); BIO *r = BIO_new(BIO_s_mem()); BIO *w = BIO_new(BIO_s_mem()); SSL *ssl = SSL_new(ctx); SSL_set_bio(ssl, r, w); SSL_set_connect_state(ssl); I want to use BIO so that I can control IO to/from the TCP layer underneath using standard system-esque calls (connect(), read(), write() on a socket fd). The transfer itself is carried out through SSL_write() then followed by BIO_read(), and BIO_write() followed by SSL_read() in/from the respective BIO *w, *r. This is all fine and dandy but how should the manual handshake be implemented? Something akin to: { char buffer[1024]; while (!SSL_is_init_finished(ssl)) { SSL_do_handshake(ssl); int nbytes; if ((nbytes = BIO_read(w, buffer, sizeof buffer)) > 0) write(fd, buffer, nbytes); else if ((nbytes = read(fd, buffer, sizeof buffer)) > 0) BIO_write(r, buffer, nbytes); } } Such a handshake can be put in wherever the server/client needs to connect, eg called during initialization. The handshake works fine when the client-server is on a localhost. However when connecting to a web server the handshake takes long to return and doesn't do the handshake either. So the question is, what further provisions need to be made to connect to a non-local web server? Or perhaps the above handshake should be integral to BIO_write() and BIO_read() calls. I'm not sure, I have not looked at the actual library sources as what SSL_() precisely does. Anyone care to send some info my way in this particular case..? From pauli at openssl.org Mon Oct 25 21:37:14 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Tue, 26 Oct 2021 07:37:14 +1000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> Message-ID: <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> It was meant for the second method only.? The first method is using different library contexts to distinguish FIPS algorithms.? Using the properties in addition is harmless and might prevent a future mistake that breaks compliance. Pauli On 26/10/21 4:46 am, Jason Schultz wrote: > Thanks again. I think most of that makes sense. Going back to your > initial response, there is something I'm not clear on. > > The second method you explained (which I don't plan to use) starting > with "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), > and then discussed calling the following API for FIPS: > ? ?EVP_set_default_properties(NULL, ?fips=yes?); > > Was the EVP_set_default_properties() call specifically and only for > the 2nd method, or did that API call apply to both the first and > second methods you explained? From reading the doc for that call, it > seems like I should be doing it if I use the first method as well. > > Regards, > > Jason > > ------------------------------------------------------------------------ > *From:* openssl-users on behalf of > Dr Paul Dale > *Sent:* Sunday, October 24, 2021 11:12 PM > *To:* openssl-users at openssl.org > *Subject:* Re: OpenSSL 3.0 FIPS questions > The configuration shouldn't have much impact.? You will need a fips > section specifying where the integrity check data are.? You shouldn't > need base or default sections. > > > Pauli > > On 25/10/21 5:23 am, Jason Schultz wrote: >> Thank you for your response. I think all of that makes?sense, and >> seems to accomplish what I want programmatically, limiting it to my >> application. I guess the only question I have is what about the >> config files? Should they remain as they were installed, or do I need >> to provide sections for fips, base, default, etc? >> >> Regards, >> >> Jason >> >> >> ------------------------------------------------------------------------ >> *From:* openssl-users >> on behalf of Dr Paul Dale >> >> *Sent:* Sunday, October 24, 2021 12:28 AM >> *To:* openssl-users at openssl.org >> >> *Subject:* Re: OpenSSL 3.0 FIPS questions >> Oops, the second time this occurs "defp = >> OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = >> OSSL_PROVIDER_load(NULL, "default");" >> >> >> Pauli >> >> On 24/10/21 10:06 am, Dr Paul Dale wrote: >>> defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetson23 at hotmail.com Tue Oct 26 19:17:01 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Tue, 26 Oct 2021 19:17:01 +0000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> Message-ID: Thanks for all of the help so far. Unfortunately, I'm still struggling with this. There could be a number of issues, starting with the installation of OpenSSL. I basically followed the documentation and did the following: ./Configure enable-fips make make test make install The "make test" actually fails, but I did not troubleshoot as it seems like a lot of systems have issues here. But I know the .so produced when I build my application is linking to the correct OpenSSL libraries (libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0. I've tried a number of combinations trying to make this work, starting with the code from Dr. Paul Dale in a previous message: fips_libctx = OSSL_LIB_CTX_new(); if (!fips_libctx) // error handling non_fips_libctx = OSSL_LIB_CTX_new(); if (!non_fips_libctx) // error handling fipsp = OSSL_PROVIDER_load(fips_libctx, "fips"); if (fipsp == NULL) { /* error handling */ } basep = OSSL_PROVIDER_load(fips_libctx, "base"); if (basep == NULL) { /* error handling */ } defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); if (defp == NULL) { /* error handling */ } /* Disallow falling back to the default library context */ nullp = OSSL_PROVIDER_load(NULL, "null"); if (nullp == NULL) { /*error handling */ } With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, which is probably expected given the fips provider didn't load. At that point, I wasn't sure if my application was using the (correct) config file in /usr/local/ssl/. I don't have any environment variables set up, and would prefer not to have to set any to get this to work. So I changed the provider load for FIPS to use OSSL_LIB_CTX_load_config(): if (!OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf")) // error handling This seems to work load the provider; however, there are two separate problems at this point. If FIPS is enabled by my application creating the SSL_CTX with the FIPS library context fails, returning NULL. If FIPS is turned OFF by my application, creating an SSL_CTX with the non_fips_libctx is successful, but later calling X509_get_pubkey() returns NULL, implying maybe something is wrong with the non_fips_libctx as well. I've tried other combinations, but at this point I'm just guessing. Is there anything obvious I could be missing and I should be checking? Thanks, Jason ________________________________ From: Dr Paul Dale Sent: Monday, October 25, 2021 9:37 PM To: Jason Schultz ; openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions It was meant for the second method only. The first method is using different library contexts to distinguish FIPS algorithms. Using the properties in addition is harmless and might prevent a future mistake that breaks compliance. Pauli On 26/10/21 4:46 am, Jason Schultz wrote: Thanks again. I think most of that makes sense. Going back to your initial response, there is something I'm not clear on. The second method you explained (which I don't plan to use) starting with "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then discussed calling the following API for FIPS: EVP_set_default_properties(NULL, ?fips=yes?); Was the EVP_set_default_properties() call specifically and only for the 2nd method, or did that API call apply to both the first and second methods you explained? From reading the doc for that call, it seems like I should be doing it if I use the first method as well. Regards, Jason ________________________________ From: openssl-users on behalf of Dr Paul Dale Sent: Sunday, October 24, 2021 11:12 PM To: openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions The configuration shouldn't have much impact. You will need a fips section specifying where the integrity check data are. You shouldn't need base or default sections. Pauli On 25/10/21 5:23 am, Jason Schultz wrote: Thank you for your response. I think all of that makes sense, and seems to accomplish what I want programmatically, limiting it to my application. I guess the only question I have is what about the config files? Should they remain as they were installed, or do I need to provide sections for fips, base, default, etc? Regards, Jason ________________________________ From: openssl-users on behalf of Dr Paul Dale Sent: Sunday, October 24, 2021 12:28 AM To: openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");" Pauli On 24/10/21 10:06 am, Dr Paul Dale wrote: defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); -------------- next part -------------- An HTML attachment was scrubbed... URL: From kory at avatarci.com Tue Oct 26 20:13:27 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Tue, 26 Oct 2021 13:13:27 -0700 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> Message-ID: Did you follow the steps in README-FIPS.md and do the ?fipsinstall?? > On Oct 26, 2021, at 12:17 PM, Jason Schultz wrote: > > Thanks for all of the help so far. Unfortunately, I'm still struggling with this. There could be a number of issues, starting with the installation of OpenSSL. I basically followed the documentation and did the following: > > ./Configure enable-fips > make > make test > make install > > The "make test" actually fails, but I did not troubleshoot as it seems like a lot of systems have issues here. But I know the .so produced when I build my application is linking to the correct OpenSSL libraries (libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0. > > I've tried a number of combinations trying to make this work, starting with the code from Dr. Paul Dale in a previous message: > > fips_libctx = OSSL_LIB_CTX_new(); > if (!fips_libctx) > // error handling > > non_fips_libctx = OSSL_LIB_CTX_new(); > if (!non_fips_libctx) > // error handling > > fipsp = OSSL_PROVIDER_load(fips_libctx, "fips"); > if (fipsp == NULL) > { > /* error handling */ > } > > > basep = OSSL_PROVIDER_load(fips_libctx, "base"); > if (basep == NULL) > { > /* error handling */ > } > > defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); > if (defp == NULL) > { > /* error handling */ > } > > /* Disallow falling back to the default library context */ > > nullp = OSSL_PROVIDER_load(NULL, "null"); > if (nullp == NULL) > { > /*error handling */ > } > > With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, which is probably expected given the fips provider didn't load. > > At that point, I wasn't sure if my application was using the (correct) config file in /usr/local/ssl/. I don't have any environment variables set up, and would prefer not to have to set any to get this to work. So I changed the provider load for FIPS to use OSSL_LIB_CTX_load_config(): > > if (!OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf")) > // error handling > > This seems to work load the provider; however, there are two separate problems at this point. If FIPS is enabled by my application creating the SSL_CTX with the FIPS library context fails, returning NULL. > > If FIPS is turned OFF by my application, creating an SSL_CTX with the non_fips_libctx is successful, but later calling X509_get_pubkey() returns NULL, implying maybe something is wrong with the non_fips_libctx as well. > > I've tried other combinations, but at this point I'm just guessing. Is there anything obvious I could be missing and I should be checking? > > Thanks, > > Jason > > > From: Dr Paul Dale > Sent: Monday, October 25, 2021 9:37 PM > To: Jason Schultz ; openssl-users at openssl.org > Subject: Re: OpenSSL 3.0 FIPS questions > > It was meant for the second method only. The first method is using different library contexts to distinguish FIPS algorithms. Using the properties in addition is harmless and might prevent a future mistake that breaks compliance. > > Pauli > > On 26/10/21 4:46 am, Jason Schultz wrote: >> Thanks again. I think most of that makes sense. Going back to your initial response, there is something I'm not clear on. >> >> The second method you explained (which I don't plan to use) starting with "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then discussed calling the following API for FIPS: >> EVP_set_default_properties(NULL, ?fips=yes?); >> >> Was the EVP_set_default_properties() call specifically and only for the 2nd method, or did that API call apply to both the first and second methods you explained? From reading the doc for that call, it seems like I should be doing it if I use the first method as well. >> >> Regards, >> >> Jason >> >> From: openssl-users on behalf of Dr Paul Dale >> Sent: Sunday, October 24, 2021 11:12 PM >> To: openssl-users at openssl.org >> Subject: Re: OpenSSL 3.0 FIPS questions >> >> The configuration shouldn't have much impact. You will need a fips section specifying where the integrity check data are. You shouldn't need base or default sections. >> >> >> Pauli >> >> On 25/10/21 5:23 am, Jason Schultz wrote: >>> Thank you for your response. I think all of that makes sense, and seems to accomplish what I want programmatically, limiting it to my application. I guess the only question I have is what about the config files? Should they remain as they were installed, or do I need to provide sections for fips, base, default, etc? >>> >>> Regards, >>> >>> Jason >>> >>> >>> From: openssl-users on behalf of Dr Paul Dale >>> Sent: Sunday, October 24, 2021 12:28 AM >>> To: openssl-users at openssl.org >>> Subject: Re: OpenSSL 3.0 FIPS questions >>> >>> Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");" >>> >>> >>> Pauli >>> >>> On 24/10/21 10:06 am, Dr Paul Dale wrote: >>>> defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetson23 at hotmail.com Tue Oct 26 20:42:13 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Tue, 26 Oct 2021 20:42:13 +0000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> Message-ID: Kory- If I'm understanding the README-FIPS.md file, I don't need to do the "fipsinstall", it is done during the normal installation process when FIPS is enabled, presumably with the "enable-fips" on the configure command: Installing the FIPS module ========================== If the FIPS provider is enabled, it gets installed automatically during the normal installation process. Simply follow the normal procedure (configure, make, make test, make install) as described in the [INSTALL](INSTALL.md) file. For example, on Unix the final command $ make install effectively executes the following install targets $ make install_sw $ make install_ssldirs $ make install_docs $ make install_fips # for `enable-fips` only It looks like the fips.so shared object was produced from these steps on my system, in /usr/local/lib64/ossl-modules/. Are you saying I still needed to do "openssl fipsinstall" after the 4 steps I already did? Thanks, Jason ________________________________ From: Kory Hamzeh Sent: Tuesday, October 26, 2021 8:13 PM To: Jason Schultz Cc: Dr Paul Dale ; openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions Did you follow the steps in README-FIPS.md and do the ?fipsinstall?? On Oct 26, 2021, at 12:17 PM, Jason Schultz > wrote: Thanks for all of the help so far. Unfortunately, I'm still struggling with this. There could be a number of issues, starting with the installation of OpenSSL. I basically followed the documentation and did the following: ./Configure enable-fips make make test make install The "make test" actually fails, but I did not troubleshoot as it seems like a lot of systems have issues here. But I know the .so produced when I build my application is linking to the correct OpenSSL libraries (libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0. I've tried a number of combinations trying to make this work, starting with the code from Dr. Paul Dale in a previous message: fips_libctx = OSSL_LIB_CTX_new(); if (!fips_libctx) // error handling non_fips_libctx = OSSL_LIB_CTX_new(); if (!non_fips_libctx) // error handling fipsp = OSSL_PROVIDER_load(fips_libctx, "fips"); if (fipsp == NULL) { /* error handling */ } basep = OSSL_PROVIDER_load(fips_libctx, "base"); if (basep == NULL) { /* error handling */ } defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); if (defp == NULL) { /* error handling */ } /* Disallow falling back to the default library context */ nullp = OSSL_PROVIDER_load(NULL, "null"); if (nullp == NULL) { /*error handling */ } With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, which is probably expected given the fips provider didn't load. At that point, I wasn't sure if my application was using the (correct) config file in /usr/local/ssl/. I don't have any environment variables set up, and would prefer not to have to set any to get this to work. So I changed the provider load for FIPS to use OSSL_LIB_CTX_load_config(): if (!OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf")) // error handling This seems to work load the provider; however, there are two separate problems at this point. If FIPS is enabled by my application creating the SSL_CTX with the FIPS library context fails, returning NULL. If FIPS is turned OFF by my application, creating an SSL_CTX with the non_fips_libctx is successful, but later calling X509_get_pubkey() returns NULL, implying maybe something is wrong with the non_fips_libctx as well. I've tried other combinations, but at this point I'm just guessing. Is there anything obvious I could be missing and I should be checking? Thanks, Jason ________________________________ From: Dr Paul Dale > Sent: Monday, October 25, 2021 9:37 PM To: Jason Schultz >; openssl-users at openssl.org > Subject: Re: OpenSSL 3.0 FIPS questions It was meant for the second method only. The first method is using different library contexts to distinguish FIPS algorithms. Using the properties in addition is harmless and might prevent a future mistake that breaks compliance. Pauli On 26/10/21 4:46 am, Jason Schultz wrote: Thanks again. I think most of that makes sense. Going back to your initial response, there is something I'm not clear on. The second method you explained (which I don't plan to use) starting with "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then discussed calling the following API for FIPS: EVP_set_default_properties(NULL, ?fips=yes?); Was the EVP_set_default_properties() call specifically and only for the 2nd method, or did that API call apply to both the first and second methods you explained? From reading the doc for that call, it seems like I should be doing it if I use the first method as well. Regards, Jason ________________________________ From: openssl-users on behalf of Dr Paul Dale Sent: Sunday, October 24, 2021 11:12 PM To: openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions The configuration shouldn't have much impact. You will need a fips section specifying where the integrity check data are. You shouldn't need base or default sections. Pauli On 25/10/21 5:23 am, Jason Schultz wrote: Thank you for your response. I think all of that makes sense, and seems to accomplish what I want programmatically, limiting it to my application. I guess the only question I have is what about the config files? Should they remain as they were installed, or do I need to provide sections for fips, base, default, etc? Regards, Jason ________________________________ From: openssl-users on behalf of Dr Paul Dale Sent: Sunday, October 24, 2021 12:28 AM To: openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");" Pauli On 24/10/21 10:06 am, Dr Paul Dale wrote: defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); -------------- next part -------------- An HTML attachment was scrubbed... URL: From kory at avatarci.com Tue Oct 26 21:15:10 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Tue, 26 Oct 2021 14:15:10 -0700 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> Message-ID: <8B1E6202-C02C-4E5D-B8B2-E941C61C745E@avatarci.com> Actually, if you are running on the same machine that you built OpenSSL, you are fine. I cross-compile and have to do a fipsinstall each time. My apologies. > On Oct 26, 2021, at 12:17 PM, Jason Schultz wrote: > > Thanks for all of the help so far. Unfortunately, I'm still struggling with this. There could be a number of issues, starting with the installation of OpenSSL. I basically followed the documentation and did the following: > > ./Configure enable-fips > make > make test > make install > > The "make test" actually fails, but I did not troubleshoot as it seems like a lot of systems have issues here. But I know the .so produced when I build my application is linking to the correct OpenSSL libraries (libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0. > > I've tried a number of combinations trying to make this work, starting with the code from Dr. Paul Dale in a previous message: > > fips_libctx = OSSL_LIB_CTX_new(); > if (!fips_libctx) > // error handling > > non_fips_libctx = OSSL_LIB_CTX_new(); > if (!non_fips_libctx) > // error handling > > fipsp = OSSL_PROVIDER_load(fips_libctx, "fips"); > if (fipsp == NULL) > { > /* error handling */ > } > > > basep = OSSL_PROVIDER_load(fips_libctx, "base"); > if (basep == NULL) > { > /* error handling */ > } > > defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); > if (defp == NULL) > { > /* error handling */ > } > > /* Disallow falling back to the default library context */ > > nullp = OSSL_PROVIDER_load(NULL, "null"); > if (nullp == NULL) > { > /*error handling */ > } > > With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, which is probably expected given the fips provider didn't load. > > At that point, I wasn't sure if my application was using the (correct) config file in /usr/local/ssl/. I don't have any environment variables set up, and would prefer not to have to set any to get this to work. So I changed the provider load for FIPS to use OSSL_LIB_CTX_load_config(): > > if (!OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf")) > // error handling > > This seems to work load the provider; however, there are two separate problems at this point. If FIPS is enabled by my application creating the SSL_CTX with the FIPS library context fails, returning NULL. > > If FIPS is turned OFF by my application, creating an SSL_CTX with the non_fips_libctx is successful, but later calling X509_get_pubkey() returns NULL, implying maybe something is wrong with the non_fips_libctx as well. > > I've tried other combinations, but at this point I'm just guessing. Is there anything obvious I could be missing and I should be checking? > > Thanks, > > Jason > > > From: Dr Paul Dale > Sent: Monday, October 25, 2021 9:37 PM > To: Jason Schultz ; openssl-users at openssl.org > Subject: Re: OpenSSL 3.0 FIPS questions > > It was meant for the second method only. The first method is using different library contexts to distinguish FIPS algorithms. Using the properties in addition is harmless and might prevent a future mistake that breaks compliance. > > Pauli > > On 26/10/21 4:46 am, Jason Schultz wrote: >> Thanks again. I think most of that makes sense. Going back to your initial response, there is something I'm not clear on. >> >> The second method you explained (which I don't plan to use) starting with "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then discussed calling the following API for FIPS: >> EVP_set_default_properties(NULL, ?fips=yes?); >> >> Was the EVP_set_default_properties() call specifically and only for the 2nd method, or did that API call apply to both the first and second methods you explained? From reading the doc for that call, it seems like I should be doing it if I use the first method as well. >> >> Regards, >> >> Jason >> >> From: openssl-users on behalf of Dr Paul Dale >> Sent: Sunday, October 24, 2021 11:12 PM >> To: openssl-users at openssl.org >> Subject: Re: OpenSSL 3.0 FIPS questions >> >> The configuration shouldn't have much impact. You will need a fips section specifying where the integrity check data are. You shouldn't need base or default sections. >> >> >> Pauli >> >> On 25/10/21 5:23 am, Jason Schultz wrote: >>> Thank you for your response. I think all of that makes sense, and seems to accomplish what I want programmatically, limiting it to my application. I guess the only question I have is what about the config files? Should they remain as they were installed, or do I need to provide sections for fips, base, default, etc? >>> >>> Regards, >>> >>> Jason >>> >>> >>> From: openssl-users on behalf of Dr Paul Dale >>> Sent: Sunday, October 24, 2021 12:28 AM >>> To: openssl-users at openssl.org >>> Subject: Re: OpenSSL 3.0 FIPS questions >>> >>> Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");" >>> >>> >>> Pauli >>> >>> On 24/10/21 10:06 am, Dr Paul Dale wrote: >>>> defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetson23 at hotmail.com Tue Oct 26 21:16:39 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Tue, 26 Oct 2021 21:16:39 +0000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: <8B1E6202-C02C-4E5D-B8B2-E941C61C745E@avatarci.com> References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> <8B1E6202-C02C-4E5D-B8B2-E941C61C745E@avatarci.com> Message-ID: Ah, OK. Yes, I am running on the same machine. Thanks for clarifying. ________________________________ From: Kory Hamzeh Sent: Tuesday, October 26, 2021 9:15 PM To: Jason Schultz Cc: Dr Paul Dale ; openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions Actually, if you are running on the same machine that you built OpenSSL, you are fine. I cross-compile and have to do a fipsinstall each time. My apologies. On Oct 26, 2021, at 12:17 PM, Jason Schultz > wrote: Thanks for all of the help so far. Unfortunately, I'm still struggling with this. There could be a number of issues, starting with the installation of OpenSSL. I basically followed the documentation and did the following: ./Configure enable-fips make make test make install The "make test" actually fails, but I did not troubleshoot as it seems like a lot of systems have issues here. But I know the .so produced when I build my application is linking to the correct OpenSSL libraries (libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0. I've tried a number of combinations trying to make this work, starting with the code from Dr. Paul Dale in a previous message: fips_libctx = OSSL_LIB_CTX_new(); if (!fips_libctx) // error handling non_fips_libctx = OSSL_LIB_CTX_new(); if (!non_fips_libctx) // error handling fipsp = OSSL_PROVIDER_load(fips_libctx, "fips"); if (fipsp == NULL) { /* error handling */ } basep = OSSL_PROVIDER_load(fips_libctx, "base"); if (basep == NULL) { /* error handling */ } defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); if (defp == NULL) { /* error handling */ } /* Disallow falling back to the default library context */ nullp = OSSL_PROVIDER_load(NULL, "null"); if (nullp == NULL) { /*error handling */ } With the code like the above, the OSSL_PROVIDER_load() calls fails for fips. If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and returns NULL, which is probably expected given the fips provider didn't load. At that point, I wasn't sure if my application was using the (correct) config file in /usr/local/ssl/. I don't have any environment variables set up, and would prefer not to have to set any to get this to work. So I changed the provider load for FIPS to use OSSL_LIB_CTX_load_config(): if (!OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf")) // error handling This seems to work load the provider; however, there are two separate problems at this point. If FIPS is enabled by my application creating the SSL_CTX with the FIPS library context fails, returning NULL. If FIPS is turned OFF by my application, creating an SSL_CTX with the non_fips_libctx is successful, but later calling X509_get_pubkey() returns NULL, implying maybe something is wrong with the non_fips_libctx as well. I've tried other combinations, but at this point I'm just guessing. Is there anything obvious I could be missing and I should be checking? Thanks, Jason ________________________________ From: Dr Paul Dale > Sent: Monday, October 25, 2021 9:37 PM To: Jason Schultz >; openssl-users at openssl.org > Subject: Re: OpenSSL 3.0 FIPS questions It was meant for the second method only. The first method is using different library contexts to distinguish FIPS algorithms. Using the properties in addition is harmless and might prevent a future mistake that breaks compliance. Pauli On 26/10/21 4:46 am, Jason Schultz wrote: Thanks again. I think most of that makes sense. Going back to your initial response, there is something I'm not clear on. The second method you explained (which I don't plan to use) starting with "Alternatively,..." included the calls to OSSL_PRIVIDER_load(), and then discussed calling the following API for FIPS: EVP_set_default_properties(NULL, ?fips=yes?); Was the EVP_set_default_properties() call specifically and only for the 2nd method, or did that API call apply to both the first and second methods you explained? From reading the doc for that call, it seems like I should be doing it if I use the first method as well. Regards, Jason ________________________________ From: openssl-users on behalf of Dr Paul Dale Sent: Sunday, October 24, 2021 11:12 PM To: openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions The configuration shouldn't have much impact. You will need a fips section specifying where the integrity check data are. You shouldn't need base or default sections. Pauli On 25/10/21 5:23 am, Jason Schultz wrote: Thank you for your response. I think all of that makes sense, and seems to accomplish what I want programmatically, limiting it to my application. I guess the only question I have is what about the config files? Should they remain as they were installed, or do I need to provide sections for fips, base, default, etc? Regards, Jason ________________________________ From: openssl-users on behalf of Dr Paul Dale Sent: Sunday, October 24, 2021 12:28 AM To: openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions Oops, the second time this occurs "defp = OSSL_PROVIDER_load(non_fips_libctx, "default");" it should be "defp = OSSL_PROVIDER_load(NULL, "default");" Pauli On 24/10/21 10:06 am, Dr Paul Dale wrote: defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); -------------- next part -------------- An HTML attachment was scrubbed... URL: From vrastic at yahoo.com Wed Oct 27 10:28:28 2021 From: vrastic at yahoo.com (Zlatko Vrastic) Date: Wed, 27 Oct 2021 10:28:28 +0000 (UTC) Subject: Fw: openssl s_client privatekey engine pkcs11 - no SSL_connect:SSLv3/TLS write certificate verify In-Reply-To: <907130639.144125.1634909110213@mail.yahoo.com> References: <907130639.144125.1634909110213.ref@mail.yahoo.com> <907130639.144125.1634909110213@mail.yahoo.com> Message-ID: <314880972.1415913.1635330508458@mail.yahoo.com> ----- Forwarded Message ----- From: Zlatko Vrastic To: "openssl-users at openssl.org" Sent: Friday, October 22, 2021, 03:25:10 PM GMT+2Subject: openssl s_client privatekey engine pkcs11 - no SSL_connect:SSLv3/TLS write certificate verify When using openssl s_client ...... -keyform engine -engine pkcs11 -key 0:00 there is no SSL_connect:SSLv3/TLS write certificate verify step in handshake protocol and server rejects connection. Connection is https get to get token for further communication. During this https get tls1.2 is used as protocol. Connecting to server with Windows and Visual Studio https request is good with pfx or with smart card, we get token. On Linux openssl+opensc connection with client.pem and privatekey.pem extracted from pfx certificate is ok, we get token. When we use smart card with openssl+opensc we get authorisation denied, the ssl client is not sending SSL_connect:SSLv3/TLS write certificate verify. Comparing log from ssl, the initial handshake is the same, when we send get request string, after that handshake is different. good communication when used client.pem and privatekey.pem SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully SSL_connect:SSLv3/TLS read hello request SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:SSLv3/TLS read server certificate SSL_connect:SSLv3/TLS read server key exchange SSL_connect:SSLv3/TLS read server certificate request SSL_connect:SSLv3/TLS read server done SSL_connect:SSLv3/TLS write client certificate SSL_connect:SSLv3/TLS write client key exchange SSL_connect:SSLv3/TLS write certificate verify SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS read change cipher spec SSL_connect:SSLv3/TLS read finished read R BLOCK HTTP/1.1 200 OK missing write certificate verify when using gids smartcard:? -keyform engine -engine pkcs11 -key 0:00 (works the same used also: -keyform engine -engine pkcs11 -key "pkcs11:id=%00;type=private" ) SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully SSL_connect:SSLv3/TLS read hello request SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:SSLv3/TLS read server certificate SSL_connect:SSLv3/TLS read server key exchange SSL_connect:SSLv3/TLS read server certificate request SSL_connect:SSLv3/TLS read server done SSL_connect:SSLv3/TLS write client certificate SSL_connect:SSLv3/TLS write client key exchange SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS read change cipher spec SSL_connect:SSLv3/TLS read finished read R BLOCK HTTP/1.1 401 Unauthorized Do You have any suggestions on what to try? We debugged and verified that the openssl engine pkcs11 through opensc is working good. Do not know how to specify to s_client to send SSLv3/TLS write certificate verify. When this is not sent we get rejected from the server. Another issue we had was with cipher suites. Server usually works with ECDHE-RSA-AES256-GCM-SHA384. With openssl installed on linux this cipher is used for communication. With openssl installed on windows it returns 742F0000:error:0A080006:SSL routines:ssl_generate_param_group:EVP lib:ssl\s3_lib.c:4727: 742F0000:error:0A00013A:SSL routines:tls_process_ske_ecdhe:unable to find ecdh parameters:ssl\statem\statem_clnt.c:2140: this cipher suite is supprted from openssl when checked with ciphers commands. and later with New, (NONE), Cipher is (NONE) We skipped over this with -cipher AESGCM:!ECDHE-RSA-AES256-GCM-SHA384 by specifying to poenssl not to use this cipher, communication is swithed to New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256. But this problem with SSLv3/TLS write certificate verify is the same on linux and windows. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 27 10:34:07 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 27 Oct 2021 11:34:07 +0100 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> Message-ID: On 26/10/2021 20:17, Jason Schultz wrote: > Thanks?for all of the help so far. Unfortunately, I'm still struggling > with this. There could be a number of issues, starting with the > installation of OpenSSL. I basically followed the documentation and did > the following: > > ./Configure enable-fips > > make > > make test > > make install > > > The "make test" actually fails, but I did not troubleshoot as it seems > like a lot of systems have issues here. But I know the .so produced when > I build my application is linking to the correct OpenSSL libraries > (libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0. > > I've tried a number of combinations trying to make this work, starting > with the code from Dr. Paul Dale in a previous message: > > ? ? fips_libctx = OSSL_LIB_CTX_new(); > ? ? if (!fips_libctx) > ? ? ? ? // error handling > > ? ? non_fips_libctx = OSSL_LIB_CTX_new(); > ? ? if (!non_fips_libctx) > ? ? ? ? // error handling > > ? ? fipsp = OSSL_PROVIDER_load(fips_libctx, "fips"); > ? ? if (fipsp == NULL) > ? ? ? { > ? ? ? ? /* error handling */ > ? ? ? } > > ? ? basep = OSSL_PROVIDER_load(fips_libctx, "base"); > ? ? if (basep == NULL) > ? ? ? { > ? ? ? ? /* error handling */ > ? ? ? } > > ? ? defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); > ? ? if (defp == NULL) > ? ? ? { > ? ? ? ? /* error handling */ > ? ? ? } > > ? ? /* Disallow falling back to the default library context */ > ? ? nullp = OSSL_PROVIDER_load(NULL, "null"); > ? ? if (nullp == NULL) > ? ? ? { > ? ? ? ? /*error handling */ > ? ? ? } > > With the code like the above, the OSSL_PROVIDER_load() calls fails for > fips. If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and > returns NULL, which is probably expected given the fips provider didn't > load. > > At that point, I wasn't sure if my application was using the (correct) > config file in /usr/local/ssl/. I don't have any environment variables > set up, and would prefer not to have to set any to get this to work. So > I changed the provider load for FIPS to use?OSSL_LIB_CTX_load_config(): > > ? ? if (!OSSL_LIB_CTX_load_config(fips_libctx, > "/usr/local/ssl/openssl-fips.cnf")) What is in the /usr/local/ssl/openssl-fips.cnf config file? Does the config file attempt to activate the FIPS provider itself? Does it supply the necessary FIPS provider config parameters? Typically the config file has a ".include" directive in it which includes the necessary FIPS config params. That included file will look something like this: $ cat fipsmodule.cnf [fips_sect] activate = 1 conditional-errors = 1 security-checks = 1 module-mac = 95:06:06:D1:85:17:92:F6:7B:7D:C2:43:36:A4:59:5D:75:6F:39:E6:13:0B:4B:26:5A:1B:48:78:33:5B:BE:F0 Most likely what is happening is that the FIPS provider is failing to load. Either because it cannot find the fips.so file, or because the necessary FIPS config parameters above are not found or not correct. You can test whether a provider is actually available for use or not using the OSSL_PROVIDER_available() function call. E.g.: if (!OSSL_PROVIDER_available(fips_libctx, "fips")) { /* error handling */ } https://www.openssl.org/docs/man3.0/man3/OSSL_PROVIDER_available.html If things are failing then you might find it helpful to dump the OpenSSL error stack to try and get some clues as to what the problem might be, e.g. ERR_print_errors_fp(stdout); https://www.openssl.org/docs/man3.0/man3/ERR_print_errors_fp.html Matt From jetson23 at hotmail.com Wed Oct 27 16:28:34 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Wed, 27 Oct 2021 16:28:34 +0000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> Message-ID: Sorry, I meant to include the config information in my previous email. I should probably go back to the beginning, I've been trying a lot of different combinations without success, so unwinding to the beginning and taking one step at a time is probably appropriate. Since I want the FIPS changes limited to my application only, this is based on the response from Dr. Paul Dale earlier in the thread, the first approach he recommended, so the application code looks like this: fipsp = OSSL_PROVIDER_load(fips_libctx, "fips"); if (fipsp == NULL) { // error handling } basep = OSSL_PROVIDER_load(fips_libctx, "base"); /* can't load keys without this */ if (basep == NULL) { /* error handling */ } defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); if (defp == NULL) { /* error handling */ } Since I'm back to not using my own config file, this is the relevant content in /usr/local/ssl/openssl.cnf. Again, from Dr. Paul Dale's advice of needing a FIPS section, and not needing base or default sections: openssl_conf = openssl_init .include /usr/local/ssl/fipsmodule.cnf [openssl_init] providers = provider_sect # List of providers to load [provider_sect] default = default_sect # The fips section name should match the section name inside the # included fipsmodule.cnf. fips = fips_sect [default_sect] # activate = 1 Here is the /usr/local/ssl/fipsmodule.cnf file: [fips_sect] activate = 1 conditional-errors = 1 security-checks = 1 module-mac = E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9 With these config files and the code above, the OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the messages from the ERR_print_errors_fp() call: 2097C692B57F0000:error:1C8000D5:Provider routines:(unknown function):missing config data:providers/fips/self_test.c:289: 2097C692B57F0000:error:1C8000E0:Provider routines:(unknown function):fips module entering error state:providers/fips/self_test.c:387: 2097C692B57F0000:error:1C8000D8:Provider routines:(unknown function):self test post failure:providers/fips/fipsprov.c:706: 2097C692B57F0000:error:078C0105:common libcrypto routines:(unknown function):init fail:crypto/provider_core.c:903:name=fips So this does seem like I have something wrong as far as setup/install or configuration. I'm not sure if it's something in the config files above, or something with my application being able to find the fips.so, which was also mentioned. The code above in self_test.c that's throwing the error looks like the st parameter to SELF_TESET_post() is NULL, but I'm not sure what the actual problem is. The self test isn't set up to run correctly, the self test failed, maybe both, or maybe something else? One of the links from Matt included a function OSSL_PROVIDER_set_default_search_path(). I'm wondering if that's needed since I don't have any environment variables set up? I'm not sure what the default search path is. Jason ________________________________ From: Matt Caswell Sent: Wednesday, October 27, 2021 10:34 AM To: Jason Schultz ; Dr Paul Dale ; openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions On 26/10/2021 20:17, Jason Schultz wrote: > Thanks for all of the help so far. Unfortunately, I'm still struggling > with this. There could be a number of issues, starting with the > installation of OpenSSL. I basically followed the documentation and did > the following: > > ./Configure enable-fips > > make > > make test > > make install > > > The "make test" actually fails, but I did not troubleshoot as it seems > like a lot of systems have issues here. But I know the .so produced when > I build my application is linking to the correct OpenSSL libraries > (libssl.so.3 and libcrypto.so.3). Checking the OpenSSL version shows 3.0. > > I've tried a number of combinations trying to make this work, starting > with the code from Dr. Paul Dale in a previous message: > > fips_libctx = OSSL_LIB_CTX_new(); > if (!fips_libctx) > // error handling > > non_fips_libctx = OSSL_LIB_CTX_new(); > if (!non_fips_libctx) > // error handling > > fipsp = OSSL_PROVIDER_load(fips_libctx, "fips"); > if (fipsp == NULL) > { > /* error handling */ > } > > basep = OSSL_PROVIDER_load(fips_libctx, "base"); > if (basep == NULL) > { > /* error handling */ > } > > defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); > if (defp == NULL) > { > /* error handling */ > } > > /* Disallow falling back to the default library context */ > nullp = OSSL_PROVIDER_load(NULL, "null"); > if (nullp == NULL) > { > /*error handling */ > } > > With the code like the above, the OSSL_PROVIDER_load() calls fails for > fips. If I try to use the fips_libctx in SSL_CTX_new_ex(), it fails and > returns NULL, which is probably expected given the fips provider didn't > load. > > At that point, I wasn't sure if my application was using the (correct) > config file in /usr/local/ssl/. I don't have any environment variables > set up, and would prefer not to have to set any to get this to work. So > I changed the provider load for FIPS to use OSSL_LIB_CTX_load_config(): > > if (!OSSL_LIB_CTX_load_config(fips_libctx, > "/usr/local/ssl/openssl-fips.cnf")) What is in the /usr/local/ssl/openssl-fips.cnf config file? Does the config file attempt to activate the FIPS provider itself? Does it supply the necessary FIPS provider config parameters? Typically the config file has a ".include" directive in it which includes the necessary FIPS config params. That included file will look something like this: $ cat fipsmodule.cnf [fips_sect] activate = 1 conditional-errors = 1 security-checks = 1 module-mac = 95:06:06:D1:85:17:92:F6:7B:7D:C2:43:36:A4:59:5D:75:6F:39:E6:13:0B:4B:26:5A:1B:48:78:33:5B:BE:F0 Most likely what is happening is that the FIPS provider is failing to load. Either because it cannot find the fips.so file, or because the necessary FIPS config parameters above are not found or not correct. You can test whether a provider is actually available for use or not using the OSSL_PROVIDER_available() function call. E.g.: if (!OSSL_PROVIDER_available(fips_libctx, "fips")) { /* error handling */ } https://www.openssl.org/docs/man3.0/man3/OSSL_PROVIDER_available.html If things are failing then you might find it helpful to dump the OpenSSL error stack to try and get some clues as to what the problem might be, e.g. ERR_print_errors_fp(stdout); https://www.openssl.org/docs/man3.0/man3/ERR_print_errors_fp.html Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe at felipegasper.com Wed Oct 27 17:53:45 2021 From: felipe at felipegasper.com (Felipe Gasper) Date: Wed, 27 Oct 2021 13:53:45 -0400 Subject: =?utf-8?B?djEuMS4xOiDigJxTZWN1cmUgUmVuZWdvdGlhdGlvbiBJUyBOT1Qg?= =?utf-8?B?c3VwcG9ydGVk4oCd?= Message-ID: <127C6462-D4AE-47BA-8265-F1C836FE40F9@felipegasper.com> Hello, I?m using OpenSSL 1.1.1l to connect via s_client to a service on an AlmaLinux 8 box running OpenSSL 1.1.1g, and s_client is reporting that secure renegotiation isn?t supported: > Secure Renegotiation IS NOT supported Curiously, when I connect to a 1.0.2 server (CentOS 7), it reports that: > Secure Renegotiation IS supported Support for secure renegotiation is a ?good thing?, right? That being the case, why would the newer OpenSSL version report no support for it while the older one supports it? Thank you! Cheers, -Felipe Gasper From kory at avatarci.com Wed Oct 27 18:04:33 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Wed, 27 Oct 2021 11:04:33 -0700 Subject: Refactring FIPS_escda_sign() for OpenSSL 3.0.0 Message-ID: Hi, I am upgrading some 3RD party code which performs FIPS ECDSA AVS testing for FIPS 140-2 certification. The code uses FIPS_escda_sign(), which in Openssl-fips-2.0.5 is define as: ECDSA_SIG * FIPS_ecdsa_sign(EC_KEY *key, const unsigned char *msg, size_t msglen , const EVP_MD *mhash) The full code is here: https://github.com/majek/openssl/blob/master/fips/ecdsa/fips_ecdsavs.c I have read through all of the ECDSA sign man pages, and I cannot find a functions that is close to accepting some of the same parameter. I could use some help please. I have very little experience with ECDSA. Thanks, Kory From Sunil.Paramashivaiah at rbbn.com Thu Oct 28 04:50:52 2021 From: Sunil.Paramashivaiah at rbbn.com (Paramashivaiah, Sunil) Date: Thu, 28 Oct 2021 04:50:52 +0000 Subject: [EXTERNAL] Re: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 In-Reply-To: <1963a297-94af-5638-4678-97c312485a7f@openssl.org> References: <3b8d168c-eeb2-0813-6721-1c544c4599c4@openssl.org> <1963a297-94af-5638-4678-97c312485a7f@openssl.org> Message-ID: Hi Matt, Thanks for the help. I need get SSL members (ssl->session , ssl->ctx , ssl->references) and set SSL member (ssl->tlsext_ocsp_resp). Please let me know the Openssl 3.0 API's for the same. Thanks and Regards, Sunil -----Original Message----- From: Matt Caswell Sent: Monday, October 25, 2021 3:03 PM To: Paramashivaiah, Sunil ; openssl-users at openssl.org Cc: Kumar Mishra, Sanjeev Subject: Re: [EXTERNAL] Re: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 Caveat: I've not tested or compiled the following...but something like this: if (EVP_PKEY_is_a(evpKey, "RSA)) { keysz = EVP_PKEY_get_bits(evpKey) / 8; /* some code */ } else if (EVP_PKEY_is_a(evpKey, "EC")) { char *name; size_t namesize; if (!EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, NULL, 0, &namesize)) /* error */; name = OPENSSL_malloc(namesize + 1); if (name == NULL) /* error */ if (!EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, name, namesize + 1, 0)) /* error */ /* This gets you the curve name as a string. If you really need as * an integer you can additionally do the following - but note that * some providers might add curves that libcrypto doesn't know about * so this could fail */ ecGrpId = OBJ_txt2nid(name); if (ecGrpId == NID_undef) /* error */; OPENSSL_free(name); /* some code */ } On 25/10/2021 10:21, Paramashivaiah, Sunil wrote: > Hi Matt, > > Thanks for the reply. I need to replace the below code. > > int keysz,ecGrpId; > > switch(evpKey->type) > { > case NID_rsaEncryption: > { > if(evpKey->pkey.rsa) > { > keysz = BN_num_bits(evpKey->pkey.rsa->n); > . > . > /* some code */ > } > break; > } > case NID_X9_62_id_ecPublicKey: > { > ecGrpId = EC_GROUP_get_curve_name(evpKey->pkey.ec->group); > /* some code follows*/ > > Thanks and Regards, > Sunil > > -----Original Message----- > From: Matt Caswell > Sent: Monday, October 25, 2021 2:23 PM > To: Paramashivaiah, Sunil ; > openssl-users at openssl.org > Subject: [EXTERNAL] Re: Need Help for Code Changes to Upgrade from > OpenSSL 1.0.2 to 3.0 > > > > On 25/10/2021 05:45, Paramashivaiah, Sunil wrote: >> Hi All, >> >> ??????? I need get APIs for accessing the members of? EVP_PKEY. >> Please suggest APIs to get following members of EVP_PKEY >> >> evpkey->type , evpkey->pkey.rsa , pubKey->pkey.ec->group. > > EVP_PKEY_get_id() will get you the `evpkey->type` value. But note that in the provider world an external provider could add key types that are unknown to libcrypto. "EVP_PKEY_is_a" is a more future proof way to go. > > https://clicktime.symantec.com/3TPr6AZe5xYBkrduooQtHHv6H2?u=https%3A%2 > F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FEVP_PKEY_is_a.html > > E.g. > > if (EVP_PKEY_is_a(pkey, "RSA")) ...; > if (EVP_PKEY_is_a(pkey, "EC")) ...; > > > The "evppkey->pkey.rsa" value can be obtained via EVP_PKEY_get0_RSA() > but note that this is deprecated. You are encouraged to not use the > RSA structure at all in 3.0 (all the functions that take an RSA > structure are deprecated). So you should look at what you are trying > to do with > evpkey->pkey.rsa and refactor things to not need it. Why do you want this? > > Similar comments apply to "pubkey->pkey.ec". You can get the EC_KEY object using EVP_PKEY_get0_EC_KEY() but this is deprecated. You can get the group from an EC_KEY using EC_KEY_get0_group() - but this is also deprecated. Instead you might consider getting the "group name" for the EC key which will tell you what curve is in use, e.g. > > EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, > NULL, 0, &namesize); name = OPENSSL_malloc(namesize + 1); EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, > name, namesize + 1, 0); > > https://clicktime.symantec.com/36qEeyKryNCZ32uxNgfFe4p6H2?u=https%3A%2 > F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FEVP_PKEY_get_utf8_string_ > param.html > > Matt > > >> >> Thanks and Regards, >> >> Sunil >> >> >> Notice: This e-mail together with any attachments may contain >> information of Ribbon Communications Inc. and its Affiliates that is >> confidential and/or proprietary for the sole use of the intended >> recipient. Any review, disclosure, reliance or distribution by others >> or forwarding without express permission is strictly prohibited. If >> you are not the intended recipient, please notify the sender >> immediately and then delete all copies, including any attachments. > > Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. > Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. From matt at openssl.org Thu Oct 28 07:39:15 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 28 Oct 2021 08:39:15 +0100 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> Message-ID: <9c7b2946-99a3-6890-da5c-560390870218@openssl.org> On 27/10/2021 17:28, Jason Schultz wrote: > With these config files and the code above, the > OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the > messages from the ERR_print_errors_fp() call: > > 2097C692B57F0000:error:1C8000D5:Provider routines:(unknown > function):missing config data:providers/fips/self_test.c:289: > 2097C692B57F0000:error:1C8000E0:Provider routines:(unknown > function):fips module entering error state:providers/fips/self_test.c:387: > 2097C692B57F0000:error:1C8000D8:Provider routines:(unknown > function):self test post failure:providers/fips/fipsprov.c:706: > 2097C692B57F0000:error:078C0105:common libcrypto routines:(unknown > function):init fail:crypto/provider_core.c:903:name=fips This tells us that the fips provider has successfully loaded, but then subsequently failed during its self-test because it cannot find its config data. I can see that you have created a separate libctx for fips. However automatic loading of the config file only works for the *default* libctx. If you create your own one then you need to explicitly load the config file: if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) { /* error handling */ } Actually if you do this then you should not need to call OSSL_PROVIDER_load() explicitly to load the fips provider since you already activated it in the config file. You can either drop the explicit call to OSSL_PROVIDER_load() for the fips provider, or remove the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a minor optimisation though. Doing both is redundant but harmless. You could also load the base provider via config if you wanted to. Matt From matt at openssl.org Thu Oct 28 07:52:13 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 28 Oct 2021 08:52:13 +0100 Subject: =?UTF-8?Q?Re=3a_v1=2e1=2e1=3a_=e2=80=9cSecure_Renegotiation_IS_NOT_?= =?UTF-8?B?c3VwcG9ydGVk4oCd?= In-Reply-To: <127C6462-D4AE-47BA-8265-F1C836FE40F9@felipegasper.com> References: <127C6462-D4AE-47BA-8265-F1C836FE40F9@felipegasper.com> Message-ID: On 27/10/2021 18:53, Felipe Gasper wrote: > Support for secure renegotiation is a ?good thing?, right? That being the case, why would the newer OpenSSL version report no support for it while the older one supports it? Probably TLSv1.3 is being negotiated with the newer version. In TLSv1.3 secure renegotiation is not supported because it is irrelevant. TLSv1.3 doesn't do renegotiation at all. Matt From matt at openssl.org Thu Oct 28 09:00:11 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 28 Oct 2021 10:00:11 +0100 Subject: Refactring FIPS_escda_sign() for OpenSSL 3.0.0 In-Reply-To: References: Message-ID: <1c2fb277-b37c-528b-5593-450607f55269@openssl.org> On 27/10/2021 19:04, Kory Hamzeh wrote: > > Hi, > > I am upgrading some 3RD party code which performs FIPS ECDSA AVS testing for FIPS 140-2 certification. The code uses FIPS_escda_sign(), which in Openssl-fips-2.0.5 is define as: > > ECDSA_SIG * FIPS_ecdsa_sign(EC_KEY *key, > const unsigned char *msg, size_t msglen > , const EVP_MD *mhash) > > > The full code is here: > > https://github.com/majek/openssl/blob/master/fips/ecdsa/fips_ecdsavs.c > > I have read through all of the ECDSA sign man pages, and I cannot find a functions that is close to accepting some of the same parameter. I could use some help please. I have very little experience with ECDSA. You need to use the EVP_DigestSignInit_ex/Update/Final APIs instead. See the man page here: https://www.openssl.org/docs/man3.0/man3/EVP_DigestSignInit_ex.html To do that you will need to have the key as an EVP_PKEY instead of an EC_KEY. The code you pointed at generates a new key using EC_KEY_generate_key(). Instead you can use EVP_PKEY_Q_keygen(): https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_Q_keygen.html To get the public key x/y co-ords and the private key value you need to use EVP_PKEY_get_bn_param: https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_get_bn_param.html See also: https://www.openssl.org/docs/man3.0/man7/EVP_PKEY-EC.html Matt From guerinp at talasi.fr Thu Oct 28 09:06:15 2021 From: guerinp at talasi.fr (=?UTF-8?Q?Patrice_Gu=c3=a9rin?=) Date: Thu, 28 Oct 2021 11:06:15 +0200 Subject: pkcs12 output change between release 1.0.2 and 1.1.1 Message-ID: <9854e136-523d-576e-fe13-88d8452eb38d@talasi.fr> Hi all, The output of pkcs12 command differs between release 1.0.2 and 1.1.1. The command used is ????? openssl pkcs12 -passin pass:xxxx -nokeys -in signedcert.bin In the bag attributes, if the subject (and probably the issuer) contains bytes outside ASCII range, I get a different result and make internal unit test failed in this case. In release 1.0.2,? bytes are expressed as \xHH In release 1.1.1, they are expressed as \HH Is there a way to get compatible results ? Thank you in advance. Kind regards, Patrice. From matt at openssl.org Thu Oct 28 09:16:24 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 28 Oct 2021 10:16:24 +0100 Subject: [EXTERNAL] Re: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 In-Reply-To: References: <3b8d168c-eeb2-0813-6721-1c544c4599c4@openssl.org> <1963a297-94af-5638-4678-97c312485a7f@openssl.org> Message-ID: <8d445294-27d9-ecae-babf-4f22fe0a3827@openssl.org> On 28/10/2021 05:50, Paramashivaiah, Sunil wrote: > ssl->session SSL_get0_session(): https://www.openssl.org/docs/man3.0/man3/SSL_get_session.html Although beware: TLSv1.3 changes how sessions are established - they are created post-handshake. Read the NOTES section on the man page carefully. > ssl->ctx SSL_get_SSL_CTX() https://www.openssl.org/docs/man3.0/man3/SSL_get_SSL_CTX.html > ssl->references This is not exposed. > ssl->tlsext_ocsp_resp SSL_set_tlsext_status_ocsp_resp(); https://www.openssl.org/docs/man3.0/man3/SSL_set_tlsext_status_ocsp_resp.html Matt > Please let me know the Openssl 3.0 API's for the same. > > Thanks and Regards, > Sunil > > -----Original Message----- > From: Matt Caswell > Sent: Monday, October 25, 2021 3:03 PM > To: Paramashivaiah, Sunil ; openssl-users at openssl.org > Cc: Kumar Mishra, Sanjeev > Subject: Re: [EXTERNAL] Re: Need Help for Code Changes to Upgrade from OpenSSL 1.0.2 to 3.0 > > Caveat: I've not tested or compiled the following...but something like this: > > if (EVP_PKEY_is_a(evpKey, "RSA)) { > keysz = EVP_PKEY_get_bits(evpKey) / 8; > /* some code */ > } else if (EVP_PKEY_is_a(evpKey, "EC")) { > char *name; > size_t namesize; > > if (!EVP_PKEY_get_utf8_string_param(pkey, > OSSL_PKEY_PARAM_GROUP_NAME, > NULL, 0, &namesize)) > /* error */; > name = OPENSSL_malloc(namesize + 1); > if (name == NULL) > /* error */ > if (!EVP_PKEY_get_utf8_string_param(pkey, > OSSL_PKEY_PARAM_GROUP_NAME, > name, namesize + 1, 0)) > /* error */ > /* This gets you the curve name as a string. If you really need as > * an integer you can additionally do the following - but note that > * some providers might add curves that libcrypto doesn't know about > * so this could fail > */ > ecGrpId = OBJ_txt2nid(name); > if (ecGrpId == NID_undef) > /* error */; > OPENSSL_free(name); > /* some code */ > } > > On 25/10/2021 10:21, Paramashivaiah, Sunil wrote: >> Hi Matt, >> >> Thanks for the reply. I need to replace the below code. >> >> int keysz,ecGrpId; >> >> switch(evpKey->type) >> { >> case NID_rsaEncryption: >> { >> if(evpKey->pkey.rsa) >> { >> keysz = BN_num_bits(evpKey->pkey.rsa->n); >> . >> . >> /* some code */ >> } >> break; >> } >> case NID_X9_62_id_ecPublicKey: >> { >> ecGrpId = EC_GROUP_get_curve_name(evpKey->pkey.ec->group); >> /* some code follows*/ >> >> Thanks and Regards, >> Sunil >> >> -----Original Message----- >> From: Matt Caswell >> Sent: Monday, October 25, 2021 2:23 PM >> To: Paramashivaiah, Sunil ; >> openssl-users at openssl.org >> Subject: [EXTERNAL] Re: Need Help for Code Changes to Upgrade from >> OpenSSL 1.0.2 to 3.0 >> >> >> >> On 25/10/2021 05:45, Paramashivaiah, Sunil wrote: >>> Hi All, >>> >>> ??????? I need get APIs for accessing the members of? EVP_PKEY. >>> Please suggest APIs to get following members of EVP_PKEY >>> >>> evpkey->type , evpkey->pkey.rsa , pubKey->pkey.ec->group. >> >> EVP_PKEY_get_id() will get you the `evpkey->type` value. But note that in the provider world an external provider could add key types that are unknown to libcrypto. "EVP_PKEY_is_a" is a more future proof way to go. >> >> https://clicktime.symantec.com/3TPr6AZe5xYBkrduooQtHHv6H2?u=https%3A%2 >> F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FEVP_PKEY_is_a.html >> >> E.g. >> >> if (EVP_PKEY_is_a(pkey, "RSA")) ...; >> if (EVP_PKEY_is_a(pkey, "EC")) ...; >> >> >> The "evppkey->pkey.rsa" value can be obtained via EVP_PKEY_get0_RSA() >> but note that this is deprecated. You are encouraged to not use the >> RSA structure at all in 3.0 (all the functions that take an RSA >> structure are deprecated). So you should look at what you are trying >> to do with >> evpkey->pkey.rsa and refactor things to not need it. Why do you want this? >> >> Similar comments apply to "pubkey->pkey.ec". You can get the EC_KEY object using EVP_PKEY_get0_EC_KEY() but this is deprecated. You can get the group from an EC_KEY using EC_KEY_get0_group() - but this is also deprecated. Instead you might consider getting the "group name" for the EC key which will tell you what curve is in use, e.g. >> >> EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, >> NULL, 0, &namesize); name = OPENSSL_malloc(namesize + 1); EVP_PKEY_get_utf8_string_param(pkey, OSSL_PKEY_PARAM_GROUP_NAME, >> name, namesize + 1, 0); >> >> https://clicktime.symantec.com/36qEeyKryNCZ32uxNgfFe4p6H2?u=https%3A%2 >> F%2Fwww.openssl.org%2Fdocs%2Fman3.0%2Fman3%2FEVP_PKEY_get_utf8_string_ >> param.html >> >> Matt >> >> >>> >>> Thanks and Regards, >>> >>> Sunil >>> >>> >>> Notice: This e-mail together with any attachments may contain >>> information of Ribbon Communications Inc. and its Affiliates that is >>> confidential and/or proprietary for the sole use of the intended >>> recipient. Any review, disclosure, reliance or distribution by others >>> or forwarding without express permission is strictly prohibited. If >>> you are not the intended recipient, please notify the sender >>> immediately and then delete all copies, including any attachments. >> >> Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. >> > > Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. > From matt at openssl.org Thu Oct 28 09:36:12 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 28 Oct 2021 10:36:12 +0100 Subject: pkcs12 output change between release 1.0.2 and 1.1.1 In-Reply-To: <9854e136-523d-576e-fe13-88d8452eb38d@talasi.fr> References: <9854e136-523d-576e-fe13-88d8452eb38d@talasi.fr> Message-ID: <4c41745a-33f3-151c-040e-6e99c1c1e5d6@openssl.org> On 28/10/2021 10:06, Patrice Gu?rin wrote: > Hi all, > > The output of pkcs12 command differs between release 1.0.2 and 1.1.1. > > The command used is > ????? openssl pkcs12 -passin pass:xxxx -nokeys -in signedcert.bin > > In the bag attributes, if the subject (and probably the issuer) contains > bytes outside ASCII range, > I get a different result and make internal unit test failed in this case. > > In release 1.0.2,? bytes are expressed as \xHH > In release 1.1.1, they are expressed as \HH > > Is there a way to get compatible results ? Some of the command line tools offer the ability to set a "-nameopt" flag to control the format of this output. Unfortunately the pkcs12 app is not one of them, so this is not possible. Matt From guerinp at talasi.fr Thu Oct 28 10:05:39 2021 From: guerinp at talasi.fr (=?UTF-8?Q?Patrice_Gu=c3=a9rin?=) Date: Thu, 28 Oct 2021 12:05:39 +0200 Subject: pkcs12 output change between release 1.0.2 and 1.1.1 In-Reply-To: <4c41745a-33f3-151c-040e-6e99c1c1e5d6@openssl.org> References: <9854e136-523d-576e-fe13-88d8452eb38d@talasi.fr> <4c41745a-33f3-151c-040e-6e99c1c1e5d6@openssl.org> Message-ID: Hi Matt, Ok, we'll proceed by another way. Thank you for your fast answer Kinbd regards, Patrice. Matt Caswell a ?crit?: > > > On 28/10/2021 10:06, Patrice Gu?rin wrote: >> Hi all, >> >> The output of pkcs12 command differs between release 1.0.2 and 1.1.1. >> >> The command used is >> ?????? openssl pkcs12 -passin pass:xxxx -nokeys -in signedcert.bin >> >> In the bag attributes, if the subject (and probably the issuer) >> contains bytes outside ASCII range, >> I get a different result and make internal unit test failed in this >> case. >> >> In release 1.0.2,? bytes are expressed as \xHH >> In release 1.1.1, they are expressed as \HH >> >> Is there a way to get compatible results ? > > Some of the command line tools offer the ability to set a "-nameopt" > flag to control the format of this output. Unfortunately the pkcs12 > app is not one of them, so this is not possible. > > Matt > > From felipe at felipegasper.com Thu Oct 28 13:16:08 2021 From: felipe at felipegasper.com (Felipe Gasper) Date: Thu, 28 Oct 2021 09:16:08 -0400 Subject: =?utf-8?Q?Re=3A_v1=2E1=2E1=3A_=E2=80=9CSecure_Renegotiation_IS_NO?= =?utf-8?Q?T_supported=E2=80=9D?= In-Reply-To: References: <127C6462-D4AE-47BA-8265-F1C836FE40F9@felipegasper.com> Message-ID: > On Oct 28, 2021, at 03:52, Matt Caswell wrote: > > > > On 27/10/2021 18:53, Felipe Gasper wrote: >> Support for secure renegotiation is a ?good thing?, right? That being the case, why would the newer OpenSSL version report no support for it while the older one supports it? > > Probably TLSv1.3 is being negotiated with the newer version. In TLSv1.3 secure renegotiation is not supported because it is irrelevant. TLSv1.3 doesn't do renegotiation at all. Ahh, thank you. That makes sense. Would a patch that updates s_client?s verbiage be accepted? It seems like, when TLS 1.3 is in play, the note about secure renegotiation should either be omitted or altered to mention that renegotiation support is a non-issue for this TLS version. It also seems like the SECURE RENEGOTIATION section of OpenSSL?s docs could use a bit of update to mention that it?s only relevant for 1.2 and prior? Related: apparently some security-scanning tools flag any client renegotiation support as a potential vulnerability. Apparently about 10 years back it came out that renegotiations were more expensive on the server than on the client, as a result of which it was possible for a client to run a denial-of-service attack by issuing renegotiation requests over and over. Is this still an issue, or is it something that newer OpenSSLs effectively mitigate? Thank you again! Cheers, -Felipe Gasper From matt at openssl.org Thu Oct 28 13:25:48 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 28 Oct 2021 14:25:48 +0100 Subject: =?UTF-8?Q?Re=3a_v1=2e1=2e1=3a_=e2=80=9cSecure_Renegotiation_IS_NOT_?= =?UTF-8?B?c3VwcG9ydGVk4oCd?= In-Reply-To: References: <127C6462-D4AE-47BA-8265-F1C836FE40F9@felipegasper.com> Message-ID: <861abf35-6d8e-fbec-3300-7b3195f83845@openssl.org> On 28/10/2021 14:16, Felipe Gasper wrote: > > >> On Oct 28, 2021, at 03:52, Matt Caswell wrote: >> >> >> >> On 27/10/2021 18:53, Felipe Gasper wrote: >>> Support for secure renegotiation is a ?good thing?, right? That being the case, why would the newer OpenSSL version report no support for it while the older one supports it? >> >> Probably TLSv1.3 is being negotiated with the newer version. In TLSv1.3 secure renegotiation is not supported because it is irrelevant. TLSv1.3 doesn't do renegotiation at all. > > Ahh, thank you. That makes sense. > > Would a patch that updates s_client?s verbiage be accepted? Potentially into master, yes. Not into 3.0 or 1.1.1. It seems like, when TLS 1.3 is in play, the note about secure renegotiation should either be omitted or altered to mention that renegotiation support is a non-issue for this TLS version. > > It also seems like the SECURE RENEGOTIATION section of OpenSSL?s docs could use a bit of update to mention that it?s only relevant for 1.2 and prior? Fixes for the docs are always welcome - even for 3.0 and 1.1.1. > > Related: apparently some security-scanning tools flag any client renegotiation support as a potential vulnerability. Apparently about 10 years back it came out that renegotiations were more expensive on the server than on the client, as a result of which it was possible for a client to run a denial-of-service attack by issuing renegotiation requests over and over. Is this still an issue, or is it something that newer OpenSSLs effectively mitigate? Over the years there have been various problems related to renegotiation. From OpenSSL 3.0 client initiated reneg is disabled by default on the server. Note that this is different to whether the server claims support for "SECURE RENEGOTIATION". The server will still negotiate the secure renegotiation feature, but will reject attempts by the client to actually initiate reneg. Matt From thiagu.m at gmail.com Thu Oct 28 13:30:39 2021 From: thiagu.m at gmail.com (Thiagu Mohan) Date: Thu, 28 Oct 2021 19:00:39 +0530 Subject: Openssl 1.1.1l compilation issue for aix64-cc Message-ID: Openssl Version 1.1.1l I am trying to compile openssl in Aix 7.2 OS ( ./Configure aix64-cc ) While running make, receiving error "*Undeclared identifier RTLD_MEMBER" * and *"ldinfo_next" is not a member of "struct ld_info". * Any pointers will be much helpful. *Log:* *cc -I. -Iinclude -qpic -q64 -qmaxmem=16384 -qro -qroconst -qthreaded -O -DB_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/usr/mohant2/aix/openssl_1.1.1l_aix\"" -DENGINESDIR="\"/usr/mohant2/aix/openssl_1.1.1l_aix/lib/engines-1.1\"" -D_THREAD_SAFE -DNDEBUG -D_REENTRANT -D_XOPEN_SOURCE=700 -c -o crypto/dso/dso_dlfcn.o crypto/dso/dso_dlfcn.c* *"crypto/dso/dso_dlfcn.c", line 114.18: 1506-045 (S) Undeclared identifier RTLD_MEMBER."/usr/include/sys/ldr.h", line 168.9: 1506-046 (S) Syntax error."/usr/include/sys/ldr.h", line 205.5: 1506-046 (S) Syntax error."/usr/include/sys/ldr.h", line 218.5: 1506-046 (S) Syntax error."/usr/include/sys/ldr.h", line 225.5: 1506-046 (S) Syntax error."/usr/include/sys/ldr.h", line 265.45: 1506-046 (S) Syntax error."crypto/dso/dso_dlfcn.c", line 398.53: 1506-022 (S) "ldinfo_next" is not a member of "struct ld_info"."crypto/dso/dso_dlfcn.c", line 400.24: 1506-022 (S) "ldinfo_next" is not a member of "struct ld_info".make[1]: *** [crypto/dso/dso_dlfcn.o] Error 1make[1]: Leaving directory `/usr/mohant2/aix/openssl-1.1.1l'make: *** [all] Error 2* -- Regards, Thiagu Mohan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jetson23 at hotmail.com Thu Oct 28 13:49:15 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Thu, 28 Oct 2021 13:49:15 +0000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: <9c7b2946-99a3-6890-da5c-560390870218@openssl.org> References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> <9c7b2946-99a3-6890-da5c-560390870218@openssl.org> Message-ID: Thanks Matt. I actually had this working (loading the fips_libctx using the *load_config() API) but I was hitting other issues and thought I was doing something wrong (more on that later). So to review, I have my own config file, /usr/local/ssl/openssl-fips, with the relevant contents(some comments snipped): .include /usr/local/ssl/fipsmodule.cnf [openssl_init] providers = provider_sect # List of providers to load [provider_sect] default = default_sect # The fips section name should match the section name inside the # included fipsmodule.cnf. fips = fips_sect base = base_sect [default_sect] # activate = 1 [base_sect] activate = 1 And then fipsmodule.cnf contains: [fips_sect] activate = 1 conditional-errors = 1 security-checks = 1 module-mac = E4:0D:C8:C3:1E:DB:2B:30:E6:F2:49:7B:F5:BD:10:5C:9A:2B:CC:C1:33:49:31:B5:C5:AF:50:AB:82:1E:AE:C9 By activating the fips and base providers via config, my application then calls: OSSL_LIB_CTX_load_config(fips_libctx, "/usr/local/ssl/openssl-fips.cnf"); Which loads the "fips" and "base" providers in the fips_libctx, which I verify with: OSSL_PROVIDER_available(fips_libctx, "fips"); and OSSL_PROVIDER_available(fips_libctx, "base") ...and both are available. However, remember I am trying to create two non-default library contexts (from earlier code): fips_libctx = OSSL_LIB_CTX_new(); non_fips_libctx = OSSL_LIB_CTX_new(); Again, I think I have what I need for the fibs_libctx. For the non_fips_libctx, I'm calling: defp = OSSL_PROVIDER_load(non_fips_libctx, "default"); nullp = OSSL_PROVIDER_load(NULL, "null"); A call to OSSL_PROVIDER_available() says the "default" provider is available; however, I'm wondering if I should be loading the default provider via *load_config() as well? I would have to uncomment the "activate = 1" in the default section of my config though. I also still have this in my code: /* Disallow falling back to the default library context */ nullp = OSSL_PROVIDER_load(NULL, "null"); But not sure it's having any affect? I do know that later in my application, both in "FIPS" or "non-FIPS" mode, I can create an SSL_CTX with SSL_CTX_new_ex(). I also successfully call several APIs using both the fips_libctx or the non_fips_libctx, for example: status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM); status = SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM); status = SSL_CTX_check_private_key(ctx); All return successfully. So I think what I have between configuration files and API calls accomplishes what I need to. Would anyone reading this agree? I'm running into another issue that I need to troubleshoot a bit more before I add too much information and too many questions to a single message. Thanks to everyone for their help with this, things are starting to make more sense now. ________________________________ From: Matt Caswell Sent: Thursday, October 28, 2021 7:39 AM To: Jason Schultz ; Dr Paul Dale ; openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions On 27/10/2021 17:28, Jason Schultz wrote: > With these config files and the code above, the > OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the > messages from the ERR_print_errors_fp() call: > > 2097C692B57F0000:error:1C8000D5:Provider routines:(unknown > function):missing config data:providers/fips/self_test.c:289: > 2097C692B57F0000:error:1C8000E0:Provider routines:(unknown > function):fips module entering error state:providers/fips/self_test.c:387: > 2097C692B57F0000:error:1C8000D8:Provider routines:(unknown > function):self test post failure:providers/fips/fipsprov.c:706: > 2097C692B57F0000:error:078C0105:common libcrypto routines:(unknown > function):init fail:crypto/provider_core.c:903:name=fips This tells us that the fips provider has successfully loaded, but then subsequently failed during its self-test because it cannot find its config data. I can see that you have created a separate libctx for fips. However automatic loading of the config file only works for the *default* libctx. If you create your own one then you need to explicitly load the config file: if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) { /* error handling */ } Actually if you do this then you should not need to call OSSL_PROVIDER_load() explicitly to load the fips provider since you already activated it in the config file. You can either drop the explicit call to OSSL_PROVIDER_load() for the fips provider, or remove the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a minor optimisation though. Doing both is redundant but harmless. You could also load the base provider via config if you wanted to. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Oct 28 14:00:46 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 28 Oct 2021 15:00:46 +0100 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> <9c7b2946-99a3-6890-da5c-560390870218@openssl.org> Message-ID: <727d36d5-075e-ec26-ab64-ea24083ac7bb@openssl.org> On 28/10/2021 14:49, Jason Schultz wrote: > A call to OSSL_PROVIDER_available() says the "default" provider is > available;? however, I'm wondering if I should be loading the default > provider via *load_config() as well? I would have to uncomment the > "activate = 1" in the default section of my config though. This is entirely a matter of personal taste. It makes no difference functionally whether you load a provider via OSSL_PROVIDER_load() directly, or whether you do it via the config file. Obviously if you do it via a config file it gives you the ability to modify what providers get loaded later without having to recompile. If you decided to do it via config then you probably want *2* different config files. One for the fips libctx and one for the non-fips libctx. > > I also still have this in my code: > > ? ? /* Disallow falling back to the default library context */ > ? ? nullp = OSSL_PROVIDER_load(NULL, "null"); > > But not sure it's having any affect? You could attempt to test it by attempting to fetch an algorithm. We would expect it to fail if it is working as expected. E.g. EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL); if (md != NULL) { /* Should not happen! The null provider should prevent this */ } > > I do know that later in my application, both in "FIPS" or "non-FIPS" > mode, I can? create an SSL_CTX with SSL_CTX_new_ex(). I also > successfully call several APIs using both the fips_libctx or the > non_fips_libctx, for example: > > status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM); > > status = SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM); > > status = SSL_CTX_check_private_key(ctx); > > > All return successfully. So I think what I have between configuration > files and API calls accomplishes what I need to. Would anyone reading > this agree? It sounds correct from what you have described. Matt > > I'm running into another issue that I need to troubleshoot a bit more > before I add too much information and too many questions to a single > message. > > Thanks?to everyone for their help with this, things are starting to make > more sense now. > > > > ------------------------------------------------------------------------ > *From:* Matt Caswell > *Sent:* Thursday, October 28, 2021 7:39 AM > *To:* Jason Schultz ; Dr Paul Dale > ; openssl-users at openssl.org > *Subject:* Re: OpenSSL 3.0 FIPS questions > > > On 27/10/2021 17:28, Jason Schultz wrote: >> With these config files and the code above, the >> OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the >> messages from the ERR_print_errors_fp() call: >> >> 2097C692B57F0000:error:1C8000D5:Provider routines:(unknown >> function):missing config data:providers/fips/self_test.c:289: >> 2097C692B57F0000:error:1C8000E0:Provider routines:(unknown >> function):fips module entering error state:providers/fips/self_test.c:387: >> 2097C692B57F0000:error:1C8000D8:Provider routines:(unknown >> function):self test post failure:providers/fips/fipsprov.c:706: >> 2097C692B57F0000:error:078C0105:common libcrypto routines:(unknown >> function):init fail:crypto/provider_core.c:903:name=fips > > > This tells us that the fips provider has successfully loaded, but then > subsequently failed during its self-test because it cannot find its > config data. > > I can see that you have created a separate libctx for fips. However > automatic loading of the config file only works for the *default* > libctx. If you create your own one then you need to explicitly load the > config file: > > if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) { > ???? /* error handling */ > } > > Actually if you do this then you should not need to call > OSSL_PROVIDER_load() explicitly to load the fips provider since you > already activated it in the config file. You can either drop the > explicit call to OSSL_PROVIDER_load() for the fips provider, or remove > the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a > minor optimisation though. Doing both is redundant but harmless. You > could also load the base provider via config if you wanted to. > > Matt > > From Michael.Wojcik at microfocus.com Thu Oct 28 15:02:54 2021 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 28 Oct 2021 15:02:54 +0000 Subject: Openssl 1.1.1l compilation issue for aix64-cc In-Reply-To: References: Message-ID: > From: openssl-users On Behalf Of Thiagu Mohan > Sent: Thursday, 28 October, 2021 07:31 > Openssl? Version 1.1.1l > I am trying to compile openssl in Aix 7.2 OS ( ./Configure aix64-cc? ?) I don't recall seeing these, but I think the latest version of AIX we're building on is 7.1. And it looks like we're still using 1.1.1k (must not have needed the fixes from 1.1.1l). Also, I'm no longer the person doing our UNIX builds. > While running make, receiving error? > "Undeclared identifier RTLD_MEMBER"? This appears to be because _ALL_SOURCE isn't defined. >? ? ? ? ? ? and?? > "ldinfo_next" is not a member of "struct ld_info".? The ldinfo_next error is a cascade from the earlier errors reported against sys/ldr.h. I have no idea at the moment why you're getting those; it's not obvious from a quick look at the header. And at least the one on the AIX 7.1 box I checked hasn't changed since 2014. > ... > cc ?-I. -Iinclude -qpic -q64 -qmaxmem=16384 -qro -qroconst -qthreaded -O -DB_ENDIAN -DOPENSSL_PIC -DOPENSSLDIR="\"/usr/mohant2/aix/openssl_1.1.1l_aix\"" -DENGINESDIR="\"/usr/mohant2/aix/openssl_1.1.1l_aix/lib/engines-1.1\"" -D_THREAD_SAFE -DNDEBUG -D_REENTRANT -D_XOPEN_SOURCE=700 ?-c -o crypto/dso/dso_dlfcn.o crypto/dso/dso_dlfcn.c > "crypto/dso/dso_dlfcn.c", line 114.18: 1506-045 (S) Undeclared identifier RTLD_MEMBER. > "/usr/include/sys/ldr.h", line 168.9: 1506-046 (S) Syntax error. > "/usr/include/sys/ldr.h", line 205.5: 1506-046 (S) Syntax error. > "/usr/include/sys/ldr.h", line 218.5: 1506-046 (S) Syntax error. > "/usr/include/sys/ldr.h", line 225.5: 1506-046 (S) Syntax error. > "/usr/include/sys/ldr.h", line 265.45: 1506-046 (S) Syntax error. > "crypto/dso/dso_dlfcn.c", line 398.53: 1506-022 (S) "ldinfo_next" is not a member of "struct ld_info". > "crypto/dso/dso_dlfcn.c", line 400.24: 1506-022 (S) "ldinfo_next" is not a member of "struct ld_info". Try editing the Makefile and adding -D_ALL_SOURCE to see if that fixes the RTLD_MEMBER error. It might also have an effect on the ldr.h errors. If so, the Configure entry for aix-cc might need an update. -- Michael Wojcik From jetson23 at hotmail.com Thu Oct 28 17:33:41 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Thu, 28 Oct 2021 17:33:41 +0000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: <727d36d5-075e-ec26-ab64-ea24083ac7bb@openssl.org> References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> <9c7b2946-99a3-6890-da5c-560390870218@openssl.org> <727d36d5-075e-ec26-ab64-ea24083ac7bb@openssl.org> Message-ID: Thanks Matt. I think I have what I need as far as loading providers. I also did the test you suggested with EVP_MD_fetch() and things failed as expected, the fetch did not work. One other question on providers, given how I load everything, it seems like before application exit, the cleanup should be the following: OSSL_LIB_CTX_free(fips_libctx); OSSL_LIB_CTX_free(non_fips_libctx); OSSL_PROVIDER_unload(defp); Since I didn't "explicitly" load the fips and base providers with API calls, I only need to unlead the default provider, as well as free both library contexts. Also, when I did try to unload the fips and base providers, the call to OSSL_PROVIDER_unload() hung, with the following backtrace: #1 0x00007fb37f51d709 in CRYPTO_THREAD_read_lock () from /lib64/libcrypto.so.3 #2 0x00007fb37f50c068 in ossl_lib_ctx_get_data () from /lib64/libcrypto.so.3 #3 0x00007fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3 #4 0x00007fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3 #5 0x00007fb37f51b813 in ossl_provider_deactivate () from /lib64/libcrypto.so.3 #6 0x00007fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3 Thanks, Jason ________________________________ From: Matt Caswell Sent: Thursday, October 28, 2021 2:00 PM To: Jason Schultz ; Dr Paul Dale ; openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions On 28/10/2021 14:49, Jason Schultz wrote: > A call to OSSL_PROVIDER_available() says the "default" provider is > available; however, I'm wondering if I should be loading the default > provider via *load_config() as well? I would have to uncomment the > "activate = 1" in the default section of my config though. This is entirely a matter of personal taste. It makes no difference functionally whether you load a provider via OSSL_PROVIDER_load() directly, or whether you do it via the config file. Obviously if you do it via a config file it gives you the ability to modify what providers get loaded later without having to recompile. If you decided to do it via config then you probably want *2* different config files. One for the fips libctx and one for the non-fips libctx. > > I also still have this in my code: > > /* Disallow falling back to the default library context */ > nullp = OSSL_PROVIDER_load(NULL, "null"); > > But not sure it's having any affect? You could attempt to test it by attempting to fetch an algorithm. We would expect it to fail if it is working as expected. E.g. EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL); if (md != NULL) { /* Should not happen! The null provider should prevent this */ } > > I do know that later in my application, both in "FIPS" or "non-FIPS" > mode, I can create an SSL_CTX with SSL_CTX_new_ex(). I also > successfully call several APIs using both the fips_libctx or the > non_fips_libctx, for example: > > status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM); > > status = SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM); > > status = SSL_CTX_check_private_key(ctx); > > > All return successfully. So I think what I have between configuration > files and API calls accomplishes what I need to. Would anyone reading > this agree? It sounds correct from what you have described. Matt > > I'm running into another issue that I need to troubleshoot a bit more > before I add too much information and too many questions to a single > message. > > Thanks to everyone for their help with this, things are starting to make > more sense now. > > > > ------------------------------------------------------------------------ > *From:* Matt Caswell > *Sent:* Thursday, October 28, 2021 7:39 AM > *To:* Jason Schultz ; Dr Paul Dale > ; openssl-users at openssl.org > *Subject:* Re: OpenSSL 3.0 FIPS questions > > > On 27/10/2021 17:28, Jason Schultz wrote: >> With these config files and the code above, the >> OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the >> messages from the ERR_print_errors_fp() call: >> >> 2097C692B57F0000:error:1C8000D5:Provider routines:(unknown >> function):missing config data:providers/fips/self_test.c:289: >> 2097C692B57F0000:error:1C8000E0:Provider routines:(unknown >> function):fips module entering error state:providers/fips/self_test.c:387: >> 2097C692B57F0000:error:1C8000D8:Provider routines:(unknown >> function):self test post failure:providers/fips/fipsprov.c:706: >> 2097C692B57F0000:error:078C0105:common libcrypto routines:(unknown >> function):init fail:crypto/provider_core.c:903:name=fips > > > This tells us that the fips provider has successfully loaded, but then > subsequently failed during its self-test because it cannot find its > config data. > > I can see that you have created a separate libctx for fips. However > automatic loading of the config file only works for the *default* > libctx. If you create your own one then you need to explicitly load the > config file: > > if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) { > /* error handling */ > } > > Actually if you do this then you should not need to call > OSSL_PROVIDER_load() explicitly to load the fips provider since you > already activated it in the config file. You can either drop the > explicit call to OSSL_PROVIDER_load() for the fips provider, or remove > the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a > minor optimisation though. Doing both is redundant but harmless. You > could also load the base provider via config if you wanted to. > > Matt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Oct 28 18:03:20 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 28 Oct 2021 19:03:20 +0100 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> <9c7b2946-99a3-6890-da5c-560390870218@openssl.org> <727d36d5-075e-ec26-ab64-ea24083ac7bb@openssl.org> Message-ID: <111d1213-5d66-f8d6-f436-5b7c2126c9d2@openssl.org> On 28/10/2021 18:33, Jason Schultz wrote: > Thanks?Matt. I think I have what I need as far as loading providers. I > also did the test you suggested with EVP_MD_fetch() and things failed as > expected, the fetch did not work. > > One other question on providers, given how I load everything, it seems > like before application exit, the cleanup should be the following: > > ? ? OSSL_LIB_CTX_free(fips_libctx); > ? ? OSSL_LIB_CTX_free(non_fips_libctx); > ? ? OSSL_PROVIDER_unload(defp); Yes, but I would recommend unloading the default provider before freeing the libctx it is associated with. Otherwise bad things might happen. > > Since I didn't "explicitly" load the fips and base providers with API > calls, I only need to unlead the default provider, as well as free both > library contexts. Correct. > > Also, when I did try to unload the fips and base providers, the call to > OSSL_PROVIDER_unload() hung, with the following backtrace: Yeah. Don't do that. :-) Matt > > #1 ?0x00007fb37f51d709 in CRYPTO_THREAD_read_lock () from > /lib64/libcrypto.so.3 > #2 ?0x00007fb37f50c068 in ossl_lib_ctx_get_data () from > /lib64/libcrypto.so.3 > #3 ?0x00007fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3 > #4 ?0x00007fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3 > #5 ?0x00007fb37f51b813 in ossl_provider_deactivate () from > /lib64/libcrypto.so.3 > #6 ?0x00007fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3 > > Thanks, > > Jason > > > ------------------------------------------------------------------------ > *From:* Matt Caswell > *Sent:* Thursday, October 28, 2021 2:00 PM > *To:* Jason Schultz ; Dr Paul Dale > ; openssl-users at openssl.org > *Subject:* Re: OpenSSL 3.0 FIPS questions > > > On 28/10/2021 14:49, Jason Schultz wrote: >> A call to OSSL_PROVIDER_available() says the "default" provider is >> available;? however, I'm wondering if I should be loading the default >> provider via *load_config() as well? I would have to uncomment the >> "activate = 1" in the default section of my config though. > > This is entirely a matter of personal taste. It makes no difference > functionally whether you load a provider via OSSL_PROVIDER_load() > directly, or whether you do it via the config file. Obviously if you do > it via a config file it gives you the ability to modify what providers > get loaded later without having to recompile. > > If you decided to do it via config then you probably want *2* different > config files. One for the fips libctx and one for the non-fips libctx. > > >> >> I also still have this in my code: >> >>? ? ? /* Disallow falling back to the default library context */ >>? ? ? nullp = OSSL_PROVIDER_load(NULL, "null"); >> >> But not sure it's having any affect? > > You could attempt to test it by attempting to fetch an algorithm. We > would expect it to fail if it is working as expected. E.g. > > EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL); > if (md != NULL) { > ???? /* Should not happen! The null provider should prevent this */ > } > > >> >> I do know that later in my application, both in "FIPS" or "non-FIPS" >> mode, I can? create an SSL_CTX with SSL_CTX_new_ex(). I also >> successfully call several APIs using both the fips_libctx or the >> non_fips_libctx, for example: >> >> status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM); >> >> status = SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM); >> >> status = SSL_CTX_check_private_key(ctx); >> >> >> All return successfully. So I think what I have between configuration >> files and API calls accomplishes what I need to. Would anyone reading >> this agree? > > It sounds correct from what you have described. > > Matt > >> >> I'm running into another issue that I need to troubleshoot a bit more >> before I add too much information and too many questions to a single >> message. >> >> Thanks?to everyone for their help with this, things are starting to make >> more sense now. >> >> >> >> ------------------------------------------------------------------------ >> *From:* Matt Caswell >> *Sent:* Thursday, October 28, 2021 7:39 AM >> *To:* Jason Schultz ; Dr Paul Dale >> ; openssl-users at openssl.org >> *Subject:* Re: OpenSSL 3.0 FIPS questions >> >> >> On 27/10/2021 17:28, Jason Schultz wrote: >>> With these config files and the code above, the >>> OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the >>> messages from the ERR_print_errors_fp() call: >>> >>> 2097C692B57F0000:error:1C8000D5:Provider routines:(unknown >>> function):missing config data:providers/fips/self_test.c:289: >>> 2097C692B57F0000:error:1C8000E0:Provider routines:(unknown >>> function):fips module entering error state:providers/fips/self_test.c:387: >>> 2097C692B57F0000:error:1C8000D8:Provider routines:(unknown >>> function):self test post failure:providers/fips/fipsprov.c:706: >>> 2097C692B57F0000:error:078C0105:common libcrypto routines:(unknown >>> function):init fail:crypto/provider_core.c:903:name=fips >> >> >> This tells us that the fips provider has successfully loaded, but then >> subsequently failed during its self-test because it cannot find its >> config data. >> >> I can see that you have created a separate libctx for fips. However >> automatic loading of the config file only works for the *default* >> libctx. If you create your own one then you need to explicitly load the >> config file: >> >> if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) { >>? ???? /* error handling */ >> } >> >> Actually if you do this then you should not need to call >> OSSL_PROVIDER_load() explicitly to load the fips provider since you >> already activated it in the config file. You can either drop the >> explicit call to OSSL_PROVIDER_load() for the fips provider, or remove >> the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a >> minor optimisation though. Doing both is redundant but harmless. You >> could also load the base provider via config if you wanted to. >> >> Matt >> >> From kory at avatarci.com Thu Oct 28 21:46:22 2021 From: kory at avatarci.com (Kory Hamzeh) Date: Thu, 28 Oct 2021 14:46:22 -0700 Subject: Refactring FIPS_escda_sign() for OpenSSL 3.0.0 In-Reply-To: References: Message-ID: Hi Matt, I am making the changes that you suggested, I think I can get the X and Y by using EVP_PKEY_get_bn_param() with OSSL_PKEY_PARAM_EC_PUB_X and _PUB_Y. What I cannot figure out is how to get R and S. If I had an ECDSA_SIG, I would call ECDSA_SIG_get0_r() and _s(). Are there EVP_PKEY params for R and S? Thanks, Kory > On Oct 27, 2021, at 11:04 AM, Kory Hamzeh wrote: > > > Hi, > > I am upgrading some 3RD party code which performs FIPS ECDSA AVS testing for FIPS 140-2 certification. The code uses FIPS_escda_sign(), which in Openssl-fips-2.0.5 is define as: > > ECDSA_SIG * FIPS_ecdsa_sign(EC_KEY *key, > const unsigned char *msg, size_t msglen > , const EVP_MD *mhash) > > > The full code is here: > > https://github.com/majek/openssl/blob/master/fips/ecdsa/fips_ecdsavs.c > > I have read through all of the ECDSA sign man pages, and I cannot find a functions that is close to accepting some of the same parameter. I could use some help please. I have very little experience with ECDSA. > > Thanks, > Kory > > > From dfulger at gmx.com Fri Oct 29 07:54:19 2021 From: dfulger at gmx.com (Dan Fulger) Date: Fri, 29 Oct 2021 09:54:19 +0200 Subject: Openssl 1.1.1l compilation issue for aix64-cc Message-ID: An HTML attachment was scrubbed... URL: From alex.dankow at gmail.com Fri Oct 29 13:32:34 2021 From: alex.dankow at gmail.com (Alex Dankow) Date: Fri, 29 Oct 2021 20:32:34 +0700 Subject: SSL and "custom" EVP_KEY Message-ID: Hi OpenSSL team! I wrote a provider for Windows certificates and implemented "openssl ca". Now, I think it would be fun to see a HTTPS server using certificates installed in Windows storage. Certificate is loaded using load_cert_pass (taken from apps.c) with custom uri "wincert://11:22:33....", private key is loaded with load_key from apps.c too. It works, but ... When I use SSL_CTX_use_PrivateKey(ctx, myprivk) the key is declined. OpenSSL compares strings and expects "rsaEncryption", and so on instead of "MYKEY". Why ? Maybe I'm missing something, but if you built a key management system, sign interface, ciphers that allows key virtualization, why not go further ? I'm ready to implement the encryption interface, but why OpenSSL still care about key type name. In the new era of version 3, it can check if the key provides necessary interfaces. -- Alex Dankow -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Oct 29 14:12:22 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 29 Oct 2021 15:12:22 +0100 Subject: Refactring FIPS_escda_sign() for OpenSSL 3.0.0 In-Reply-To: References: Message-ID: On 28/10/2021 22:46, Kory Hamzeh wrote: > Hi Matt, > > I am making the changes that you suggested, I think I can get the X and Y by using > > EVP_PKEY_get_bn_param() with OSSL_PKEY_PARAM_EC_PUB_X and _PUB_Y. Yes. Correct. > What I cannot figure out is how to get R and S. If I had an ECDSA_SIG, I would call ECDSA_SIG_get0_r() and _s(). > > Are there EVP_PKEY params for R and S? > An ECDSA signature is just a DER encoded ECDSA_SIG structure. Therefore take the resulting signature and call d2i_ECDSA_SIG. This will enable you to access r and s. Matt > Thanks, > Kory > > > >> On Oct 27, 2021, at 11:04 AM, Kory Hamzeh wrote: >> >> >> Hi, >> >> I am upgrading some 3RD party code which performs FIPS ECDSA AVS testing for FIPS 140-2 certification. The code uses FIPS_escda_sign(), which in Openssl-fips-2.0.5 is define as: >> >> ECDSA_SIG * FIPS_ecdsa_sign(EC_KEY *key, >> const unsigned char *msg, size_t msglen >> , const EVP_MD *mhash) >> >> >> The full code is here: >> >> https://github.com/majek/openssl/blob/master/fips/ecdsa/fips_ecdsavs.c >> >> I have read through all of the ECDSA sign man pages, and I cannot find a functions that is close to accepting some of the same parameter. I could use some help please. I have very little experience with ECDSA. >> >> Thanks, >> Kory >> >> >> > From matt at openssl.org Fri Oct 29 15:11:31 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 29 Oct 2021 16:11:31 +0100 Subject: SSL and "custom" EVP_KEY In-Reply-To: References: Message-ID: <5f4633d6-cbd1-05cd-d27e-f82959224ad5@openssl.org> Hi Alex, On 29/10/2021 14:32, Alex Dankow wrote: > Hi OpenSSL team! > > I wrote a provider for Windows certificates and implemented "openssl ca". > Now, I think it would be fun to see a HTTPS server using certificates > installed in Windows storage. Nice! > > Certificate is loaded using load_cert_pass (taken from apps.c) with > custom uri "wincert://11:22:33....",? private key is loaded with > load_key from apps.c too. It works, but ... > When I use? SSL_CTX_use_PrivateKey(ctx, myprivk)? the key is declined. > OpenSSL compares strings and expects "rsaEncryption", and so on instead > of "MYKEY". Why ? It's not entirely clear to me what you are attempting here. Are your certificates/keys stored in Windows storage standard RSA/ECDSA etc certs? Or are they using some custom algorithm? If they are standard RSA/ECSDA certs then you should be using the correct standard algorithm names in you keymgmt etc and it should all "just work". Unfortunately, in 3.0, libssl only supports standard algorithms. We have discussed a "pluggable" signature scheme mechanism which would enable plugging in arbitrary algorithms but it didn't make it for 3.0: https://github.com/openssl/openssl/issues/10512 I'd still like to get back to that at some point but we don't have it yet. It should be entirely possible with the new provider architecture - and in fact we *did* add pluggable kex/kem support for libssl. But we just ran out of time with pluggable signatures. https://github.com/openssl/openssl/pull/11914 https://github.com/openssl/openssl/pull/13018 Matt > Maybe I'm missing something, but if you built a key management system, > sign interface, ciphers that allows key virtualization, why not go > further ? I'm ready to implement the encryption interface, but why > OpenSSL still care about key type name. In the new era of version 3, it > can check if the key provides necessary interfaces. > > -- > Alex Dankow > > From cristians at ceragon.com Fri Oct 29 15:40:46 2021 From: cristians at ceragon.com (Cristian Andrei Sandu) Date: Fri, 29 Oct 2021 15:40:46 +0000 Subject: FIPS POST induced failure in OpenSSL3.0.0 for FIPS 140-2 compliance Message-ID: Hi all, I'm currently updating an application from OpenSSL 1.0.2d to OpenSSL 3.0.0 in preparation for a FIPS 140-2 submission and I'm not sure how to approach the issue of induced failures for the power on self tests. In OpenSSL 1.0.2d we used to use FIPS_post_set_callback() for this purpose, by setting a callback that would trigger a failure of a specific test. The OpensSSL 3.0.0 design states that "Any special case code needed to return intermediate values (say for CAVS key generation), to display info (self test states), or change the normal flow of FIPS module code (e.g - self test failure or failing a keygen loop that supplies fixed rand values) will be controlled by embedding callbacks into the FIPS module code." Could you give me some pointers on what would be the best approach for this in OpenSSL 3.0.0? Am I supposed to use the OSSL_SELF_TEST_* APIs to replace the fips_self_test() callback inside the FIPS module or do I somehow need to patch the FIPS provider with new functionality? Any help would be greatly appreciated. Thanks, Cristian Sandu This email message and any attachments are intended solely for the use of the addressees hereof. This message and any attachments may contain information that is confidential, privileged and exempt from disclosure under applicable law. If you are not the intended recipient of this message, you are prohibited from reading, disclosing, reproducing, distributing, disseminating or otherwise using this transmission. If you have received this message in error, please promptly notify the sender at Ceragon by reply E-mail and immediately delete this message from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Oct 29 15:57:01 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 29 Oct 2021 16:57:01 +0100 Subject: FIPS POST induced failure in OpenSSL3.0.0 for FIPS 140-2 compliance In-Reply-To: References: Message-ID: <3e1fa059-bb7c-262c-3954-96757054525d@openssl.org> On 29/10/2021 16:40, Cristian Andrei Sandu wrote: > Hi all, > > I?m currently updating an application from OpenSSL 1.0.2d to OpenSSL > 3.0.0 in preparation for a FIPS 140-2 submission and I?m not sure how to > approach the issue of induced failures for the power on self tests. > > In OpenSSL 1.0.2d we used to use |FIPS_post_set_callback()||||for this > purpose, by setting a callback that would trigger a failure of a > specific test.| > > || > > The OpensSSL 3.0.0 design states that ?/Any special case code needed to > return intermediate values (say for CAVS key generation), to display > info (self test states), or change the normal flow of FIPS module code > (e.g - self test failure or failing a keygen loop that supplies fixed > rand values) will be controlled by *embedding callbacks into the FIPS > module code*.?/ > > Could you give me some pointers on what would be the best approach for > this in OpenSSL 3.0.0? ?Am I supposed to use the OSSL_SELF_TEST_* APIs > to replace the fips_self_test() callback inside the FIPS module or do I > somehow need to patch the FIPS provider with new functionality? Any help > would be greatly appreciated. See the OSSL_PROVIDER-FIPS man page here: https://www.openssl.org/docs/man3.0/man7/OSSL_PROVIDER-FIPS.html In particular see the section "SELF TESTING". See also the man page for OSSL_SELF_TEST_set_callback here: https://www.openssl.org/docs/man3.0/man3/OSSL_SELF_TEST_set_callback.html The information on self testing for provider authors may also be useful: https://www.openssl.org/docs/man3.0/man3/OSSL_SELF_TEST_new.html Basically you have to provide a callback which will get invoked during the self test. The return value from that callback can induce failures. There's an example callback on the OSSL_PROVIDER-FIPS man page I linked above which shows how to induce a corruption in the SHA1 testing. Matt From jetson23 at hotmail.com Sun Oct 31 21:21:32 2021 From: jetson23 at hotmail.com (Jason Schultz) Date: Sun, 31 Oct 2021 21:21:32 +0000 Subject: OpenSSL 3.0 FIPS questions In-Reply-To: <111d1213-5d66-f8d6-f436-5b7c2126c9d2@openssl.org> References: <4f7025cb-f24c-a2ba-44ea-5e1f94b09046@openssl.org> <003bb0a6-de42-53c4-07b1-4547c7fb9049@openssl.org> <9c7b2946-99a3-6890-da5c-560390870218@openssl.org> <727d36d5-075e-ec26-ab64-ea24083ac7bb@openssl.org> <111d1213-5d66-f8d6-f436-5b7c2126c9d2@openssl.org> Message-ID: Thanks to everyone for the help so far. I think I have things set up correctly as far as FIPS, providers, and library contexts. I'm hitting another problem that I think is related to the migration to OpenSSL 3.0, as this code works with OpenSSL 1.1.1 (and 1.0.2 before it). When looking at the documentation pages for 1.1.1 vs 3.0, I'm not seeing any differences between the OpenSSL APIs I'm calling in the 2 different release levels. Here is the sequence, I'm basically setting up my certificate and private key, both in PEM format, for the server, then I need to extract some information from them: ctx = SSL_CTX_new_ex(non_fips_libctx, NULL, TLS_method()); SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM); SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM); SSL_CTX_check_private_key(ctx); fp = fopen(, "r"); mycert = PEM_read_X509(fp, NULL, 0, NULL); pkey = X509_get_pubkey(mycert); All functions return good statuses or non-NULL pointers until the last one, X509_get_pubkey() returns NULL. I have tried this with RSA and Elliptic Curve cert/key pairs. I have tried with pairs created with OpenSSL 1.1.1 as well as 3.0 via the command line. This seems like a pretty straightforward operation, but it appears that key->pkey is NULL in the code below: EVP_PKEY *X509_PUBKEY_get0(const X509_PUBKEY *key) { if (key == NULL) { ERR_raise(ERR_LIB_X509, ERR_R_PASSED_NULL_PARAMETER); return NULL; } if (key->pkey == NULL) { /* We failed to decode the key when we loaded it, or it was never set */ ERR_raise(ERR_LIB_EVP, EVP_R_DECODE_ERROR); return NULL; } return key->pkey; } I got to this code from the error information I dumped from OpenSSL: 00079FF8647F0000:error:03000072:digital envelope routines:(unknown function):decode error:crypto/x509/x_pubkey.c:444: I can paste certificates if anyone thinks it will help, but I've tried several types of cert/key pairs, and using the command line to do "openssl x509 -pubkey..." displays the public key just fine with the certificate file in question. Here is an example of the openssl command line to create one of the cert/key pairs that hits this error: openssl req -new -x509 -nodes -newkey ec:<(openssl ecparam -name secp384r1) -keyout threecert.key -out threecert.crt -days 365 I kept this on the same "FIPS OpenSSL 3.0" thread because I'm not 100% sure it's unrelated. What am I missing here? Thanks, Jason ________________________________ From: Matt Caswell Sent: Thursday, October 28, 2021 6:03 PM To: Jason Schultz ; Dr Paul Dale ; openssl-users at openssl.org Subject: Re: OpenSSL 3.0 FIPS questions On 28/10/2021 18:33, Jason Schultz wrote: > Thanks Matt. I think I have what I need as far as loading providers. I > also did the test you suggested with EVP_MD_fetch() and things failed as > expected, the fetch did not work. > > One other question on providers, given how I load everything, it seems > like before application exit, the cleanup should be the following: > > OSSL_LIB_CTX_free(fips_libctx); > OSSL_LIB_CTX_free(non_fips_libctx); > OSSL_PROVIDER_unload(defp); Yes, but I would recommend unloading the default provider before freeing the libctx it is associated with. Otherwise bad things might happen. > > Since I didn't "explicitly" load the fips and base providers with API > calls, I only need to unlead the default provider, as well as free both > library contexts. Correct. > > Also, when I did try to unload the fips and base providers, the call to > OSSL_PROVIDER_unload() hung, with the following backtrace: Yeah. Don't do that. :-) Matt > > #1 0x00007fb37f51d709 in CRYPTO_THREAD_read_lock () from > /lib64/libcrypto.so.3 > #2 0x00007fb37f50c068 in ossl_lib_ctx_get_data () from > /lib64/libcrypto.so.3 > #3 0x00007fb37f519482 in get_provider_store () from /lib64/libcrypto.so.3 > #4 0x00007fb37f519af9 in provider_deactivate () from /lib64/libcrypto.so.3 > #5 0x00007fb37f51b813 in ossl_provider_deactivate () from > /lib64/libcrypto.so.3 > #6 0x00007fb37f518399 in OSSL_PROVIDER_unload () from /lib64/libcrypto.so.3 > > Thanks, > > Jason > > > ------------------------------------------------------------------------ > *From:* Matt Caswell > *Sent:* Thursday, October 28, 2021 2:00 PM > *To:* Jason Schultz ; Dr Paul Dale > ; openssl-users at openssl.org > *Subject:* Re: OpenSSL 3.0 FIPS questions > > > On 28/10/2021 14:49, Jason Schultz wrote: >> A call to OSSL_PROVIDER_available() says the "default" provider is >> available; however, I'm wondering if I should be loading the default >> provider via *load_config() as well? I would have to uncomment the >> "activate = 1" in the default section of my config though. > > This is entirely a matter of personal taste. It makes no difference > functionally whether you load a provider via OSSL_PROVIDER_load() > directly, or whether you do it via the config file. Obviously if you do > it via a config file it gives you the ability to modify what providers > get loaded later without having to recompile. > > If you decided to do it via config then you probably want *2* different > config files. One for the fips libctx and one for the non-fips libctx. > > >> >> I also still have this in my code: >> >> /* Disallow falling back to the default library context */ >> nullp = OSSL_PROVIDER_load(NULL, "null"); >> >> But not sure it's having any affect? > > You could attempt to test it by attempting to fetch an algorithm. We > would expect it to fail if it is working as expected. E.g. > > EVP_MD *md = EVP_MD_fetch(NULL, "SHA2-256", NULL); > if (md != NULL) { > /* Should not happen! The null provider should prevent this */ > } > > >> >> I do know that later in my application, both in "FIPS" or "non-FIPS" >> mode, I can create an SSL_CTX with SSL_CTX_new_ex(). I also >> successfully call several APIs using both the fips_libctx or the >> non_fips_libctx, for example: >> >> status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM); >> >> status = SSL_CTX_use_certificate_file(ctx,,SSL_FILETYPE_PEM); >> >> status = SSL_CTX_check_private_key(ctx); >> >> >> All return successfully. So I think what I have between configuration >> files and API calls accomplishes what I need to. Would anyone reading >> this agree? > > It sounds correct from what you have described. > > Matt > >> >> I'm running into another issue that I need to troubleshoot a bit more >> before I add too much information and too many questions to a single >> message. >> >> Thanks to everyone for their help with this, things are starting to make >> more sense now. >> >> >> >> ------------------------------------------------------------------------ >> *From:* Matt Caswell >> *Sent:* Thursday, October 28, 2021 7:39 AM >> *To:* Jason Schultz ; Dr Paul Dale >> ; openssl-users at openssl.org >> *Subject:* Re: OpenSSL 3.0 FIPS questions >> >> >> On 27/10/2021 17:28, Jason Schultz wrote: >>> With these config files and the code above, the >>> OSSL_PROVIDER_load(fips_libctx, "fips") call fails. Here are the >>> messages from the ERR_print_errors_fp() call: >>> >>> 2097C692B57F0000:error:1C8000D5:Provider routines:(unknown >>> function):missing config data:providers/fips/self_test.c:289: >>> 2097C692B57F0000:error:1C8000E0:Provider routines:(unknown >>> function):fips module entering error state:providers/fips/self_test.c:387: >>> 2097C692B57F0000:error:1C8000D8:Provider routines:(unknown >>> function):self test post failure:providers/fips/fipsprov.c:706: >>> 2097C692B57F0000:error:078C0105:common libcrypto routines:(unknown >>> function):init fail:crypto/provider_core.c:903:name=fips >> >> >> This tells us that the fips provider has successfully loaded, but then >> subsequently failed during its self-test because it cannot find its >> config data. >> >> I can see that you have created a separate libctx for fips. However >> automatic loading of the config file only works for the *default* >> libctx. If you create your own one then you need to explicitly load the >> config file: >> >> if (!OSSL_LIB_CTX_load_config(fips_libtx, "/usr/local/ssl/openssl.cnf")) { >> /* error handling */ >> } >> >> Actually if you do this then you should not need to call >> OSSL_PROVIDER_load() explicitly to load the fips provider since you >> already activated it in the config file. You can either drop the >> explicit call to OSSL_PROVIDER_load() for the fips provider, or remove >> the "activate = 1" line in "fips_sect" in fipsmodule.cnf. This is just a >> minor optimisation though. Doing both is redundant but harmless. You >> could also load the base provider via config if you wanted to. >> >> Matt >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: