Re: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1)
Thanks for the clarification, a couple of short questions - We already have a shim to index into the function table that gets loaded after run-time selecting from the 0.9.8 FIPS vs non-FIPS dll to use. I imagined that we might have to thicken the shim to accommodate selection between 0.9.8-FIPS and 1.0.1 non-FIPS (unorthodox I know but a potential short term step forward). Couldn't they be made interchangeable with appropriate changes to the shim or is there some more fundamental incompatibility? I looked at the link you provided for OpenSSL FIPS Object Module v2.0, validation certificate #1747 (thanks very much for that); another interesting consideration but I was surprised to notice that omitted from the list of supported algorithms was any mention of SHA, is no variant of SHA supported at all? Thanks again ... N -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Steve Marquess Sent: January-20-15 8:17 AM To: openssl-users@openssl.org Subject: Re: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1) On 01/19/2015 12:42 PM, Nou Dadoun wrote: The scenario that we're contemplating is having FIPS based on 0.9.8?? coexist with 1.0.1?? so the remapping at runtime would have to account for api differences within the two. This was really the upshot of my question. The 1.2 FIPS module (FIPS based on 0.9.8) is not compatible with OpenSSL 1.0.1. You need the 2.0 FIPS module for that. But I think I'm still a little confused about the FIPS-certification of OpenSSL 1.0.1??,... It's validation, not certification. I remember reading that some of the FIPS power on self-test requirements precluded a general FIPS certification, is that the case? ... I think you're conflating several issues here. What you're probably referring to is the fact that some new requirements for *new* FIPS 140-2 validations (IG 9.10 among them) mean that the source code for the 2.0 FIPS module can no longer be used as-is for new validations. Those new requirements have impacted those vendors desiring to pursue such private label or copycat validations, but has not affected the original 2.0 FIPS module that was used as the model for such private label validations. What is the status of FIPS OpenSSL certification? (Is this written up anywhere?) The OpenSSL FIPS Object Module v2.0, validation certificate #1747, remains available for use with (to date) 102 formally tested platforms: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1)
The scenario that we're contemplating is having FIPS based on 0.9.8?? coexist with 1.0.1?? so the remapping at runtime would have to account for api differences within the two. This was really the upshot of my question. But I think I'm still a little confused about the FIPS-certification of OpenSSL 1.0.1??, I remember reading that some of the FIPS power on self-test requirements precluded a general FIPS certification, is that the case? What is the status of FIPS OpenSSL certification? (Is this written up anywhere?) Thanks again ... N -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Steve Marquess Sent: January-16-15 2:26 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] OpenSSL FIPS (0.9.8) coexisting with non-FIPS (1.0.1) On 01/16/2015 04:23 PM, Nou Dadoun wrote: We are currently using FIPS and non-FIPS builds of 0.9.8 where a configuration setting can select FIPS or non-FIPS mode, loads the appropriate build and populates a function table which is used by the code for OpenSSL functionality. We would like to update the non-FIPS build to a later version (e.g. 1.0.1) which has support for TLS 1.1/1.2 (etc.) which could then co-exist with the increasingly insecure but certified FIPS build in this way. Has anybody tried this? Any gotchas come to mind? E.g. does a canister need to be used for the non-FIPS? Are there any major API changes between the two (besides APIs and/or parameter values which have been added or extended)? Is this a crazy thing to do? Thanks in advance for any relevant comments! ... N If I'm following here, you want to deploy something that uses OpenSSL 1.0.1 either with or without the FIPS module, as decided at runtime. That's a common enough scenario: those customers who must use FIPS will want that, all others either won't want or don't care about FIPS (some of them very specifically won't want it, for understandable reasons). You don't need two separate builds, a single build of one set of libraries can be used for both purposes. We call that the FIPS capable OpenSSL: build openssl 1.0.1 with the fips build time option in the presence of a FIPS module. You wind up with the same libcrypto and libssl libraries that you know and love. That one set of libraries can be used for either purpose: use them without calling FIPS_mode_set() and they behave like stock 1.0.1. Call FIPS_mode_set() to enable the FIPS module of operation and your application will automatically be using the embedded FIPS module (with non-approved crypto operations disabled). -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
RE: TLSv1.1 and TLSv1.2
Just following up on this I notice that support for v1.1 and v1.2 were added in: Changes between 1.0.0h and 1.0.1 [14 Mar 2012] We upgraded to 1.0.0o for our server recently and in our SSLv3 disabling testing, we discovered that the linux build appears to support 1.1 and 1.2 (using the openssl s_client command line interface) but the Windows version doesn't; since they're both built from the same source, is there any explanation for this that I'm not catching - does the change line above imply that some support for 1.1 and 1.2 was included in some later versions of 1.0.0? -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Matt Caswell Sent: October-20-14 4:08 PM To: openssl-users@openssl.org Subject: Re: TLSv1.1 and TLSv1.2 On 20/10/14 23:59, Nou Dadoun wrote: This should be a short question (for a change), am I correct in assuming that the earliest version of openssl which provided support for TLSv1.1 and TLSv1.2 is openssl 1.0.1? i.e. there's no support for those in 0.9.8 (soon to be deprecated) or 1.0.0? One of our products uses 0.9.8 for the FIPS certification and I'm now seeing that it doesn't seem to support 1.1 or 1.2. Correct. You can check the change log here: https://www.openssl.org/news/changelog.html See the entries for TLS1.1 and TLS1.2 support under the section titled Changes between 1.0.0h and 1.0.1 [14 Mar 2012]. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL_MODE_SEND_FALLBACK_SCSV option
This is the first time I've seen this point of view expressed but it does make evident sense - after all, the whole idea of falling back is to find a mutually acceptable version. However it conflicts with some of the previous advice I've seen on the list which recommended that SSL_MODE_SEND_FALLBACK_SCSV *always* be set to prevent downgrade from v1.1 to v1.2 for example. Any consensus? ... N -Original Message- ... Unconditionally setting SSL_MODE_SEND_FALLBACK_SCSV (if by default or after user configuration) is a time bomb-your client application will break once the server implements TLS 1.3 (or any newer TLS version than what is supported by the OpenSSL version you use). Extremely few applications have to deal with SSL_MODE_SEND_FALLBACK_SCSV. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL_MODE_SEND_FALLBACK_SCSV option
Well I think I'm completely confused about this option now; always when you fall back seems to suggest that falling back is an application level operation (as opposed to openssl-implemented behaviour), is it? i.e. is the onus on the client application to retry with a lower version if it wants to? What then is the purpose of the option? Maybe the following would clarify it - is there code in the new release of openssl to recognize and act on this new option (other than simply sending the option down the wire to be handled by application code)? Is there a simple example of a scenario where it would be used? Is there documentation anywhere that describes how fall back is performed? Thanks ... N -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Salz, Rich Sent: October-20-14 11:49 AM To: openssl-users@openssl.org Subject: RE: SSL_MODE_SEND_FALLBACK_SCSV option When I said always I meant always when you fall back I was being too terse and not clear enough. Hope this helps. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Nou Dadoun Sent: Monday, October 20, 2014 7:08 PM To: openssl-users@openssl.org Subject: RE: SSL_MODE_SEND_FALLBACK_SCSV option This is the first time I've seen this point of view expressed but it does make evident sense - after all, the whole idea of falling back is to find a mutually acceptable version. However it conflicts with some of the previous advice I've seen on the list which recommended that SSL_MODE_SEND_FALLBACK_SCSV *always* be set to prevent downgrade from v1.1 to v1.2 for example. Any consensus? ... N -Original Message- ... Unconditionally setting SSL_MODE_SEND_FALLBACK_SCSV (if by default or after user configuration) is a time bomb-your client application will break once the server implements TLS 1.3 (or any newer TLS version than what is supported by the OpenSSL version you use). Extremely few applications have to deal with SSL_MODE_SEND_FALLBACK_SCSV. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL_MODE_SEND_FALLBACK_SCSV option
It certainly does, thanks to you and Rich for the clarification ... N -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Matt Caswell Sent: October-20-14 1:40 PM To: openssl-users@openssl.org Subject: Re: SSL_MODE_SEND_FALLBACK_SCSV option On 20/10/14 21:10, Nou Dadoun wrote: Well I think I'm completely confused about this option now; always when you fall back seems to suggest that falling back is an application level operation (as opposed to openssl-implemented behaviour), is it? i.e. is the onus on the client application to retry with a lower version if it wants to? What then is the purpose of the option? A ClientHello handshake message sent by the client will give the lowest and the highest SSL/TLS version supported. The server is expected to select the highest one of those that it also supports. Normally that's all you need to do and there is no need for the fall back option. However some buggy servers have been seen to be version intolerant, i.e. if the client sends a maximum supported version in the ClientHello higher than the one the server supports then the connection fails...even though the server does actually support a lower version that the client also supports. Frankly most applications don't need to worry about this. However some browsers have tried to work around the problem by sending a second ClientHello with a lower maximum supported version if they fail with the initial ClientHello. This is called fallback and is one of the issues that was exploited in POODLE. The simple answer in most cases is don't worry about it and don't do fallback unless you really have to. If you do then its entirely within the control of the client...openssl (client) does not do this automatically. If you decide to do it, then you should set SSL_MODE_SEND_FALLBACK_SCSV. Maybe the following would clarify it - is there code in the new release of openssl to recognize and act on this new option (other than simply sending the option down the wire to be handled by application code)? OpenSSL on the server will appropriately respond when it sees a request with the option set. You do not need to do anything for this...it will handle it automatically. The application only needs to do anything if it is acting as a client and it wants to do fallback (as described above). Is there a simple example of a scenario where it would be used? Is there documentation anywhere that describes how fall back is performed? Jeff Walton has provided some example code on the wiki: https://wiki.openssl.org/index.php/SSL_MODE_SEND_FALLBACK_SCSV Hope that helps Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
TLSv1.1 and TLSv1.2
This should be a short question (for a change), am I correct in assuming that the earliest version of openssl which provided support for TLSv1.1 and TLSv1.2 is openssl 1.0.1? i.e. there's no support for those in 0.9.8 (soon to be deprecated) or 1.0.0? One of our products uses 0.9.8 for the FIPS certification and I'm now seeing that it doesn't seem to support 1.1 or 1.2. thanks ... N __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Please document the new SSL_MODE_SEND_FALLBACK_SCSV
Since this is the users list (as opposed to the dev list) I’m a little confused
about point 2 there; my understanding from the sketchy descriptions I’ve read
is that the fallback to a lower version is automatically done by openssl on
connect failure as opposed to something similar to the code snippet below being
present in application code. (i.e. I’m not sure whether you intend the “client”
in that description to be openssl library code or user application code which
calls into the library). Thanks … N
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Jakob Bohm
Sent: October-17-14 7:59 AM
To: openssl-users@openssl.org
Subject: Please document the new SSL_MODE_SEND_FALLBACK_SCSV
The new SSL_MODE_SEND_FALLBACK_SCSV option is badly documented in
the wiki and man pages, which is going to cause a lot of problems
when people everywhere rush to incorporate the security fixes into
their code.
In particular, I find the following to be fully undocumented (except
by trying to read the code):
1. SSL_MODE_SEND_FALLBACK_SCSV was introduced in versions 1.0.1j,
1.0.0o and 0.9.8zc, not way back when SSL_CTX_set_mode() itself
was introduced. The information at the bottom of that manpage
needs to say that, like it already does for SSL_MODE_AUTO_RETRY.
2. [ THIS IS A GUESS ]
SSL_MODE_SEND_FALLBACK_SCSV should only be set if the client
contains code like the following:
/* pseudo code */
SSL_try_connect_(supporting versions x..y)
if (failed) {
SSL_try_connect_(supporting versions x..y-1)
if (failed) {
SSL_try_connect_(supporting versions x..y-2)
... (etc.)
}
}
In which case that code needs to change to
/* pseudo code */
SSL_try_connect_(supporting versions x..y)
/* No SSL_MODE_SEND_FALLBACK_SCSV when trying with highest
attempted y */
if (failed) {
SSL_try_connect_(supporting versions x..y-1, SSL_MODE_SEND_FALLBACK_SCSV)
if (failed) {
SSL_try_connect_(supporting versions x..y-2,
SSL_MODE_SEND_FALLBACK_SCSV)
... (etc.)
}
}
(Note: The Internet draft says (in very technical terms) when an
SSL client should send the message, not when an application should
tell any given SSL library to do so, because that answer is expected
to differ between OpenSSL, Mozilla NSS, Microsoft SCHANNEL,
MatrixSSL and other SSL libraries).
3. Unlike the other SSL_MODE_ options, SSL_MODE_SEND_FALLBACK_SCSV
is not about an internal API behavior.
4. Why this isn't SSL_OPTION_SEND_FALLBACK_SCSV (there is probably
a good reason, but it isn't documented).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://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
Use of TLS_FALLBACK_SCSV
A few short (simple) questions about the use of TLS_FALLBACK_SCSV since we’re currently upgrading to the latest openssl releases. We don’t establish sessions with any other products than our own clients and servers. We’ve already disabled the use of SSLv3 in both our client and server releases going forward, is there any advantage in also using TLS_FALLBACK_SCSV – i.e. will there be any benefit in connecting to our already deployed clients and servers? (I actually don’t think that we’re vulnerable to POODLE since we don’t use anything like encrypted cookies or repeated messages that could be used to exploit padding changes to “peel off” decoded chunks. Is there any other mechanism to exploit this would make us vulnerable?) Where in the session establishment is TLS_FALLBACK_SCSV used and how would we incorporate it? I think a lot of folks will probably have these or similar questions, is there a FAQ somewhere to address this? Thanks in advance … N
RE: Use of TLS_FALLBACK_SCSV
But my understanding is that it requires the same content to be submitted repeatedly within a single session with manipulations to the padding to incrementally decrypt the content; we use ssl to protect our session establishment - think of a SIP call, SIP INVITE (offer) in one direction and SIP ACK (accept/refuse) in the other to establish session parameters and then the ssl connection is torn down and a different (non-ssl) encryption mechanism is used to protect the actual media stream. Any attempt to retransmit either INVITE or ACK will abort the session and in any case, no further sensitive material is sent subsequently to the ACK in the ssl session (there’s the equivalent of a BYE/BYE ACK). We plan to disable sslv3 anyway because we want to avoid being at risk in the future (and you point out a good argument for disabling the fallback in general) but within our controlled scenario, I don’t think we’re vulnerable to a POODLE attack unless there’s something I’m missing … N From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Salz, Rich Sent: October-16-14 4:24 PM To: openssl-users@openssl.org Subject: RE: Use of TLS_FALLBACK_SCSV It does not matter who you talk to. With a POODLE attack, your content can be decrypted. Cookies, etc., were just used as an example. Disabling ssl3 is a good thing. But set the fallback because silently dropping from tls 1.2 to tls 1.1 is bad. It’s done during the handshake process as part of the cipher negotiation. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
RE: End of the line for OpenSSL Fips?
Just as a short comment, our fips/non-fips usage could probably satisfy this requirement; we wrap openssl in an external api that routes through a function pointer table. Then at run-time we can fill in the function pointers with the fips functions or the non-fips functions depending on which mode is desired; it wouldn't take much modification to delay loading the fips function pointers until the POST is complete as long as the client code doesn't choke on a not ready yet return code. --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: Steve Marquess [mailto:marqu...@opensslfoundation.com] Sent: July 17, 2013 4:55 PM To: openssl-users@openssl.org Cc: Nou Dadoun Subject: Re: End of the line for OpenSSL Fips? On 07/16/2013 08:10 PM, Nou Dadoun wrote: Since I hadn't looked for a while, I thought that I'd see where the current Openssl FIPS work stood and found this: http://www.opensslfoundation.com/fips/ig95.html Surprised that I hadn't heard about this previously but if I'm reading it correctly, it seems to effectively kill any future Openssl FIPS certifications although it appears that our current certification remains valid. That is a definite possibility. At best any new validation would be very expensive even by the grim standards of previous OpenSSL FIPS Object Module validations. Sorry if this has been discussed previously but is this the case? A pointer to a previous discussion if one exists would be sufficient, thanks ... N There has been no public discussion that I know of. There is a bit of turmoil in the FIPS 140-2 arena right now, about the I.G. 9.5 and other issues. We're sitting that out until we know the final outcome. In the meantime we're only doing change letter updates to the #1747 validation. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
End of the line for OpenSSL Fips?
Since I hadn't looked for a while, I thought that I'd see where the current Openssl FIPS work stood and found this: http://www.opensslfoundation.com/fips/ig95.html Surprised that I hadn't heard about this previously but if I'm reading it correctly, it seems to effectively kill any future Openssl FIPS certifications although it appears that our current certification remains valid. Sorry if this has been discussed previously but is this the case? A pointer to a previous discussion if one exists would be sufficient, thanks ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Openssl crypto-only (? libcrypto) (visual studio?)
How about a simpler question, I've found a Stack Overflow article which mentions no-sock -DOPENSSL_NO_SOCK No socket code. as a build option to exclude socket code and even has an example! I'd like a build option which excludes assembler code as well (to allow for cross-compilation), anyone know what that might be? Or even better, a list of config options that I can use to tailor my build? This seems like basic information that should be in a man page or readme file somewhere, is it? --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: Nou Dadoun Sent: December 3, 2012 4:44 PM To: 'openssl-users@openssl.org' Subject: Openssl crypto-only (? libcrypto) (visual studio?) Hey folks, In our on-going efforts to construct something that will pass muster in the win8 app environment, I'd like to build the crypto library *only* without any socket or networking api calls and without any assembler. We're eventually building our full app using Visual Studio 2012 so having a project to do this would be ideal since it would make the build and deploy process much simpler. Anything like a VS project to build crypto only out there anywhere? Thanks .. N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Openssl crypto-only (? libcrypto) (visual studio?)
Hey folks, In our on-going efforts to construct something that will pass muster in the win8 app environment, I'd like to build the crypto library *only* without any socket or networking api calls and without any assembler. We're eventually building our full app using Visual Studio 2012 so having a project to do this would be ideal since it would make the build and deploy process much simpler. Anything like a VS project to build crypto only out there anywhere? Thanks .. N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Openssl FIPS and Boost
Hi folks, We have several projects that use openssl in both FIPS-mode and non-FIPS-mode; one of the projects that we have that does not use FIPS-mode is one that uses the Boost ASIO library in which we can reach done into the openssl properties to get properties and operations that aren't provided directly by Boost. This project currently uses openssl 0.9.8x. We're interested in moving this project to run in FIPS-mode (with a corresponding openssl version upgrade) and I was wondering if anyone here had experience in setting up a Boost project to run in FIPS-mode. Any general comments? ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Intermediate certificate verification
After I posted the question I found the earlier discussion from this year: http://www.mail-archive.com/openssl-users@openssl.org/msg66377.html Following the thread back at least indicates that I'm not the first one who made the incorrect assumption that providing an intermediate certificate as a trusted certificate was sufficient. The one issue for us is that we're attempting to bridge the windows certificate store and the openssl verification machinery. (We implement for several platforms so openssl is used in common with the windows crypto api/certificate store used to retrieve the certificates.) I can certainly load chains of certificates manually but this seems like an instance where the capi engine could be useful. Unfortunately I never found sufficient documentation to use the capi engine to interface windows and openssl due to the associated development schedule. This sounds like a well-defined small problem that could benefit from it though; are there any examples around of the capi engine used to retrieve certificates as required from a windows certificate store to do this kind of certificate verification? (i.e. a windows method that finds them dynamically) Thanks to Dave for the response ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: September 21, 2012 7:37 PM To: openssl-users@openssl.org Subject: RE: Intermediate certificate verification From: owner-openssl-us...@openssl.org On Behalf Of Nou Dadoun Sent: Friday, 21 September, 2012 15:29 Just wanted to confirm an assumption, I've got 3 x509 certificates: Root -- intermediate -- leaf I load the intermediate certificate (but not the Root certificate) into the x509_store and set up the verify_ctx to verify the leaf certificate. I then use the X509_verify_cert(verify_ctx) function for verification but the associated callback reports that the verification fails (i.e. ok == 0) with an error of 2 (unable to get issuer certificate). I assume that if I load the intermediate as a CA that I don't have to provide the Root to verify the leaf (i.e. I'm stating that I trust the intermediate as the CA). Is this correct? Does the Root also need to be loaded? No and sort-of. OpenSSL's cert_verify logic always checks to the root, even if an intermediate cert is in the truststore. Unlike some other implementations/applications. It's arguable if this is the best way, but it has been this way since at least 0.9.7, and I wouldn't hold my breath expecting a change soon. The full chain including root needs to be *available from* the X509_STORE. This can be accomplished by having them loaded, or by having a method that finds them dynamically -- like the by_dir method invoked by commandline for -CApath . This setup certainly works with 2 certs (i.e. Root -- Leaf) but I'm retrieving the certs using the windows crypto api so I want to make sure that my openssl verify assumption is correct before trying to run down the windows stuff. Anybody know offhand? Thanks .. N __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Self-signed certificate
Quick question: is there a simple openssl api call which will tell me if an x509 certificate is self-signed? ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Intermediate certificate verification
Just wanted to confirm an assumption, I've got 3 x509 certificates: Root -- intermediate -- leaf I load the intermediate certificate (but not the Root certificate) into the x509_store and set up the verify_ctx to verify the leaf certificate. I then use the X509_verify_cert(verify_ctx) function for verification but the associated callback reports that the verification fails (i.e. ok == 0) with an error of 2 (unable to get issuer certificate). I assume that if I load the intermediate as a CA that I don't have to provide the Root to verify the leaf (i.e. I'm stating that I trust the intermediate as the CA). Is this correct? Does the Root also need to be loaded? This setup certainly works with 2 certs (i.e. Root -- Leaf) but I'm retrieving the certs using the windows crypto api so I want to make sure that my openssl verify assumption is correct before trying to run down the windows stuff. Anybody know offhand? Thanks .. N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: windows 8 Metro and openssl
Sorry I wasn't clear, we do want to port to the Metro Tablet (we have comparable apps for iOS and Android) and since winsock is part of the blacklisted set of apis (i.e. the Metro App store will not accept an app that uses any of the blacklisted apis), it's effectively deprecated. We're just starting our investigations now but it doesn't look promising - the threading, event signaling model appears to be quite different than what we're using now (posix) so it looks like a rewrite is probably more likely than a port if it's even feasible. I'd appreciate hearing about anyone else's experiences vis a vis Metro/openssl etc .. N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of mar...@v.loewis.de Sent: August 3, 2012 3:36 PM To: openssl-users@openssl.org Subject: Re: windows 8 Metro and openssl Zitat von Nou Dadoun ndad...@teradici.com: Starting to look at trying to port some of our code to windows 8 metro which deprecates winsock in favour of a new WinRT networking api which appears to provide a much thicker/heavier weight abstraction in which it's not clear how to make use of tools like openssl. I think you misunderstand the change that Microsoft made in Windows 8. Winsock doesn't get deprecated at all; it remains available and supported for desktop applications. It's only Metro-style apps that need to use WinRT, and cannot use Winsock anymore. Is this totally incompatible with openssl (and probably any other open source development built on bsd sockets)? It's fairly incompatible. Notice that not only sockets are restricted, but also other APIs, like file access - even though CreateFile is still around (as CreateFile2), it can't access arbitrary files on the disk, which it would have to when loading certificate chains, private keys, and the like. Has anyone done any related investigations? I'm in the process of porting Python as a WinRT app; the sandboxing really interferes with a lot of APIs. If all you want is a TLS connection, you are better off using the WinRT API for secure communication, instead of OpenSSL (except if you want to do stuff that is not supported in WinRT). Regards, Martin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
windows 8 Metro and openssl
Starting to look at trying to port some of our code to windows 8 metro which deprecates winsock in favour of a new WinRT networking api which appears to provide a much thicker/heavier weight abstraction in which it's not clear how to make use of tools like openssl. Just wanted to throw out some initial questions for comment by anyone who may have started looking at some of this stuff - Is this totally incompatible with openssl (and probably any other open source development built on bsd sockets)? Has anyone done any related investigations? (Please no rants, I'm only interested in the technical questions at this point, not the political ones.) --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: DSA certificates from windows certificate store into openssl
Thanks very much for your clearly laid out and informative note; most of this matches my intuitive understanding of the differences but having it elucidated backed with experience is invaluable, thanks again ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: Jaaron Anderson [mailto:janders...@widener.edu] Sent: July 25, 2012 8:05 AM To: openssl-users@openssl.org Cc: Nou Dadoun Subject: Re: DSA certificates from windows certificate store into openssl Importance: High Replying to the DSA inquiry yesterday Nou Dadoun First thing is RSA certificate has RSA keys and DSA certificate has Diffie-Hellman (DH) keys. In SSL, Diffie-Hellman is done for key exchange to create in each end a common shared secret. Thereafter, the channel is secure using the secret not the DH keys. DSA is primarily for digital signature to check the authenticity as well as integrity. Under OpenSSL, you can load both RSA and DSA certificates and key pairs in the SSL_CTX and SSL structure. If you use a DSA certificate, you must load DH keys. Although the RSA algorithm is used for both key exchange and signing operations, DSA can be used only for signing. Therefore, DH is used as the key agreement algorithm with a DSA certificate in an SSL application. Nonetheless, see this link on using the DH keys @ http://h71000.www7.hp.com/doc/83final/ba554_90007/ch06s06.html @ http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html#DESCRIPTION DSA is not really used interchanged with RSA. Is either former or latter. RSA and DSA certificates and keys are incompatible. An SSL client that has only an RSA certificate and key cannot establish a connection with an SSL server that has only a DSA certificate and key. Check out this article which used DSA or RSA as server certificate. Java based @http://www.novell.com/documentation/extend52/Docs/help/AppServer/books/admS ecurity.html#1021296 Openssl based @ http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html#d0e3109 See the Table of cipher suites in the above article which illustrate the encryption strength avail. E.g. DSA cert - TLS_DHE_DSS_WITH_AES_256_CBC_SHA or RSA cert - TLS_DHE_RSA_WITH_AES_256_CBC_SHA Now there is also TLS1.2. Coming back, RSA certificates are commonly used for SSL, SSL servers that use DSA certificates are rare. Just a quick compare is that, DSA is faster at signing. RSA is faster at verifying. I see DSA for key exchange/sign only purpose while RSA can encrypt and sign. Hth Aaron Anderson janders...@widener.edu Widener University 610-499-1049 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: DSA certificates from windows certificate store into openssl
Thanks Jakob! I received the suggestion of using the CAPI engine from this list when I initially laid out my problem earlier in the year; unfortunately I couldn't find any documentation on how to use it let alone tailor its functionality to my requirements (e.g. selecting certificates based on friendly name with some rudimentary wildcard sni matching etc.) I suppose I could use the CAPI directly to select the certificate if I could tell the CAPI engine to do ssl-required cryptographic operations using that certificate subsequently. We're currently working with 0.98n (upgrading is on the horizon but not imminent) - is there any documentation anywhere on how this might be accomplished? Thanks again ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jakob Bohm Sent: July 25, 2012 2:22 AM To: openssl-users@openssl.org Subject: Re: DSA certificates from windows certificate store into openssl On 24-07-2012 19:31, Nou Dadoun wrote: Hey folks, I recently added a facility to our code base to retrieve a certificate and private key from a windows certificate store (using the windows crypto api) and converted it to a form usable by openssl. The certificate part was easy, the key a little trickier, involving the creation of a new rsa key pair in openssl and then modifying the parameters to match those derived from the privatekeyblob pulled from the windows cert data structure. You are doing it very, very wrong. A key feature of MS CryptoApi (and of most other engines) is that they are designed not to give you the key, ever. To get the privatekeyblob from CryptoApi, the key store has to be badly misconfigured (specifically, the key has to be stored in the registry *and* marked as exportable with an password that your code can access without user assistance). The right way is to use the engine functionality in OpenSSL to let OpenSSL use the key without ever extracting it from CryptoAPI. This works by telling OpenSSL to use the engine for CryptoAPI to do the secret key operation (DSA signing in your current case), the engine for CryptoAPI will then turn the OpenSSL DSA signing call into a CryptoAPI signing call, which CryptoAPI can then perform without exporting or otherwise revealing the secret key. For FIPS certified uses, you then need to enable FIPS mode in both OpenSSL (so OpenSSL will only use the FIPS certified and approved algorithms) and in CryptoAPI (this is set in Administrative Tools - Local Security Policy - Security Settings - Local Policies - Security Options - System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing). For added security, install a FIPS certified hardware key storage (such as certain models of Spyrus smart cards) and its Windows drivers so its keys are then reached through CryptoAPI calls (to CryptoAPI, the registry stored keys are just a fallback driver emulating such hardware with less security). Alternatively, you could install the Windows PKCS#11 driver for the hardware and use OpenSSL's pkcs11 engine to access it, but someone recently posted problems using the PKCS#11 engine with FIPS enabled. This was all done for RSA keys and although I had a number of false starts, it wasn't too painful (once I'd arranged for exportable keys and got out of windows api land as quickly as possible). We've just had a customer request to support the use of DSA certificates which I know little about (so far), can the same general process be used to extract/convert DSA keys (I'm assuming that the certificate encoding is essentially the same). Does anyone have experience with this? Any pointers or links to documentation for how this might be done? Thanks in advance N -- Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 call:+4531131610 This message is only for its intended recipient, delete if misaddressed. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
DSA certificates from windows certificate store into openssl
Hey folks, I recently added a facility to our code base to retrieve a certificate and private key from a windows certificate store (using the windows crypto api) and converted it to a form usable by openssl. The certificate part was easy, the key a little trickier, involving the creation of a new rsa key pair in openssl and then modifying the parameters to match those derived from the privatekeyblob pulled from the windows cert data structure. This was all done for RSA keys and although I had a number of false starts, it wasn't too painful (once I'd arranged for exportable keys and got out of windows api land as quickly as possible). We've just had a customer request to support the use of DSA certificates which I know little about (so far), can the same general process be used to extract/convert DSA keys (I'm assuming that the certificate encoding is essentially the same). Does anyone have experience with this? Any pointers or links to documentation for how this might be done? Thanks in advance N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: DSA certificates from windows certificate store into openssl
I'm going to back up and ask an even more basic question which appears to be surprisingly elusive - how is a DSA key/certificate used in establishing an ssl connection? I understand how an RSA key/cert ssl handshake proceeds but if the DSA key is used only for signatures, how is a secure ssl tunnel established? i.e. how do you securely agree on a symmetric key for further secure communications? (Which is how I assume things proceed.) Any pointers? N. --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Nou Dadoun Sent: July 24, 2012 10:31 AM To: openssl-users@openssl.org Subject: DSA certificates from windows certificate store into openssl Hey folks, I recently added a facility to our code base to retrieve a certificate and private key from a windows certificate store (using the windows crypto api) and converted it to a form usable by openssl. The certificate part was easy, the key a little trickier, involving the creation of a new rsa key pair in openssl and then modifying the parameters to match those derived from the privatekeyblob pulled from the windows cert data structure. This was all done for RSA keys and although I had a number of false starts, it wasn't too painful (once I'd arranged for exportable keys and got out of windows api land as quickly as possible). We've just had a customer request to support the use of DSA certificates which I know little about (so far), can the same general process be used to extract/convert DSA keys (I'm assuming that the certificate encoding is essentially the same). Does anyone have experience with this? Any pointers or links to documentation for how this might be done? Thanks in advance N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
FIPS doesn't verify certificate with 1024-bit keys
Odd problem, I've been overhauling our x509 certificate handling and I've run into an issue where the standard openssl x509 verification mechanism fails to verify a certificate with a 1024-bit key when run with the FIPS version of the library loaded but which verifies it with the non-FIPS version. All other key lengths and certificates appear to behave the same way with both. By the standard mechanism I mean: m_x509_store = X509_STORE_new_fn(); X509_STORE_set_verify_cb_func(m_x509_store, verify_callback); result =X509_STORE_add_cert_fn(m_x509_store, ca_cert); verify_ctx = X509_STORE_CTX_new_fn(); result = X509_STORE_CTX_init_fn(verify_ctx, m_x509_store, cert_to_verify, NULL); result = X509_verify_cert_fn(verify_ctx); (the _fn suffix is because we populate a fn table depending on whether we're using fips versions or not.) The verify_callback(int ok, X509_STORE_CTX *stor) appears to be called twice, the first time with ok == 1, the second time with ok == 0 and the error log: certificate signature failure. When observing a variation of this earlier, I'd thought that a unit test had left something in a funky state in switching from fips to non-fips (and I'd asked about the fact that there wasn't an api to completely remove and cleanup openssl but this is a much more specific issue.) Two questions: why is the verify callback called twice, once with ok==1 and the second with ok==0 (when called with the non-fips library both oks are ==1) - why two calls? Why is it failing with the fips library and passing with the non-fips library - does it have anything to do with the 1024 bit key? (i.e. 2048 and 4096-key certs both work, and the ca cert has a 2048-bit key) Thanks ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS doesn't verify certificate with 1024-bit keys
Here's the certificate which is failing: Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: CN=www.casofti.com, ST=BC, C=CA/emailAddress=dniko...@casofti.com, O=Teradici CA Validity Not Before: Mar 20 23:12:14 2012 GMT Not After : Mar 20 23:12:14 2013 GMT Subject: CN=www.terasofti.com, ST=BC, C=CA, O=tera_test_1024 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:a8:35:18:8f:a2:4f:79:99:70:57:37:bf:f7:f6: ee:d8:6f:3b:fe:1b:c1:da:be:55:a0:f9:c4:d4:39: a4:99:dd:b3:9f:d4:bd:0a:3a:50:7d:ad:f2:b6:29: 22:b3:3f:1e:c1:45:da:49:8b:43:fd:62:9a:94:c9: bd:f5:54:96:c8:a1:d1:f8:0d:b7:a6:7d:54:00:72: 10:59:13:7c:b1:4f:93:d7:75:76:23:ea:14:8b:f8: f5:59:c8:6a:f4:b7:f6:cd:0f:8e:f9:f5:65:d4:91: af:48:87:3f:fa:da:c0:94:0a:57:5d:7e:fe:32:f8: 70:e4:c8:9f:3d:44:c2:ef:bd Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Signature Algorithm: md5WithRSAEncryption Is it failing because of the (unapproved) md5 signature algorithm? ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: June 18, 2012 10:45 AM To: openssl-users@openssl.org Subject: Re: FIPS doesn't verify certificate with 1024-bit keys On Mon, Jun 18, 2012, Nou Dadoun wrote: Why is it failing with the fips library and passing with the non-fips library - does it have anything to do with the 1024 bit key? (i.e. 2048 and 4096-key certs both work, and the ca cert has a 2048-bit key) Do you get an additional error from ERR_print_errors_fp(stderr)? Is the key size 1024 bits exactly or 1023? What digest algorithm is used? Is it FIPS approved SHA1 or SHA2 or an unapproved algorithm like MD5? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS doesn't verify certificate with 1024-bit keys
Sorry accidentally hit send, the oddity is (as I mentioned before) that comparable certificates with larger keys using the same signing algorithm pass verification. E.g. this one is passing: Certificate: Data: Version: 3 (0x2) Serial Number: 3 (0x3) Signature Algorithm: md5WithRSAEncryption Issuer: CN=www.casofti.com, ST=BC, C=CA/emailAddress=dniko...@casofti.com, O=Teradici CA Validity Not Before: Jun 15 16:45:07 2012 GMT Not After : Sep 21 16:45:06 2020 GMT Subject: CN=pcoip_test_2048.com, ST=BC, C=CA, O=pcoip_test_2048 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:b3:30:6d:1a:5f:54:cd:f3:6a:12:da:36:0e:ee: ef:0d:62:0f:8e:0b:94:75:2c:cf:f8:cc:46:d6:88: f7:a2:7c:8d:8f:63:25:b0:c5:8c:c9:77:ce:63:64: df:af:7d:5f:0c:fc:c1:a1:e6:86:47:08:04:08:2e: 29:02:25:81:fe:16:1c:4f:f3:92:b7:27:ff:17:94: dd:00:1e:6f:9a:ac:f6:d3:98:26:d3:80:03:8a:cd: 18:d1:e1:f1:3e:6a:ef:cc:59:f1:71:b9:86:98:5e: 33:41:b5:4d:19:1d:e2:db:ae:a2:dd:e3:ed:31:f1: 7b:3f:6f:85:13:ee:61:68:cf:84:bc:a5:aa:19:d8: 15:9b:47:02:c7:70:ef:db:b2:68:0d:d3:48:79:a1: 6e:07:20:38:96:03:1e:f1:42:4a:89:60:42:e4:11: 2f:b2:44:9a:84:40:bd:34:cd:ca:e6:ca:ca:eb:1f: ff:1d:31:be:09:94:2c:85:af:32:94:bf:e9:74:42: c4:39:a4:50:18:e2:73:ec:0b:db:c1:bc:b7:e4:37: 5d:56:88:0d:83:88:e7:46:50:ea:36:78:00:80:40: 99:3f:d5:80:f5:7a:b1:ca:cb:b6:22:c6:a5:e3:42: 91:5a:5f:ab:09:d4:f5:29:32:bd:97:88:99:52:4d: dd:97 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Signature Algorithm: md5WithRSAEncryption N. --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: Nou Dadoun Sent: June 18, 2012 11:06 AM To: 'openssl-users@openssl.org' Subject: RE: FIPS doesn't verify certificate with 1024-bit keys Here's the certificate which is failing: Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: md5WithRSAEncryption Issuer: CN=www.casofti.com, ST=BC, C=CA/emailAddress=dniko...@casofti.com, O=Teradici CA Validity Not Before: Mar 20 23:12:14 2012 GMT Not After : Mar 20 23:12:14 2013 GMT Subject: CN=www.terasofti.com, ST=BC, C=CA, O=tera_test_1024 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:a8:35:18:8f:a2:4f:79:99:70:57:37:bf:f7:f6: ee:d8:6f:3b:fe:1b:c1:da:be:55:a0:f9:c4:d4:39: a4:99:dd:b3:9f:d4:bd:0a:3a:50:7d:ad:f2:b6:29: 22:b3:3f:1e:c1:45:da:49:8b:43:fd:62:9a:94:c9: bd:f5:54:96:c8:a1:d1:f8:0d:b7:a6:7d:54:00:72: 10:59:13:7c:b1:4f:93:d7:75:76:23:ea:14:8b:f8: f5:59:c8:6a:f4:b7:f6:cd:0f:8e:f9:f5:65:d4:91: af:48:87:3f:fa:da:c0:94:0a:57:5d:7e:fe:32:f8: 70:e4:c8:9f:3d:44:c2:ef:bd Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Signature Algorithm: md5WithRSAEncryption Is it failing because of the (unapproved) md5 signature algorithm? ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: June 18, 2012 10:45 AM To: openssl-users@openssl.org Subject: Re: FIPS doesn't verify certificate with 1024-bit keys On Mon, Jun 18, 2012, Nou Dadoun wrote: Why is it failing with the fips library and passing with the non-fips library - does it have anything to do with the 1024 bit key? (i.e. 2048 and 4096-key certs both work, and the ca cert has a 2048-bit key) Do you get an additional error from ERR_print_errors_fp(stderr)? Is the key size 1024 bits exactly or 1023? What digest algorithm is used? Is it FIPS approved SHA1 or SHA2 or an unapproved algorithm like MD5? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: FIPS doesn't verify certificate with 1024-bit keys
It passes OK with the usual verify utility but that's not surprising since it passes verification if I'm not using FIPS, I don't imagine there's any way to force the verify utility to use the FIPS routines; in any case, I'm happy to send them to you offline ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: June 18, 2012 11:58 AM To: openssl-users@openssl.org Subject: Re: FIPS doesn't verify certificate with 1024-bit keys On Mon, Jun 18, 2012, Nou Dadoun wrote: Sorry accidentally hit send, the oddity is (as I mentioned before) that comparable certificates with larger keys using the same signing algorithm pass verification. E.g. this one is passing: Can you reproduce this using the verify utility and the -verbose option? If so please post the certificates, privately to me if you wish. Note that the signature on the root CA is not checked by default so it can use any signature algorithm. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
X509 Subject Alternative Name
Hi folks, I'm looking for openssl information on extracting a certificate's list of Subject Alternative names for matching a query substring to select a certificate in particular contexts. All the openssl sample code that I've managed to find seems to be more heavy-weight than I'm interested in using a GENERAL_NAMES and associated data structures to extract the names based on types (e.g. GEN_DNS, GEN_EMAIL, GEN_URI which I can't find details about) - I'm happy to use this but I can't find any documentation on it (which certainly hasn't stopped me before). But I thought I'd throw out a general query, is there any simple mechanism for simply extracting the string (or strings) which define the x509 Subject Alternative Names for simple string matching? Thanks ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Openssl wildcard certificate handling
Hi folks, just wanted to throw out a request for pointers about whether openssl has any built-in support (or sample code) for matching/handling wildcard certificates. (I know that it has support for generating them, I'm particularly looking for samples of matching in an sni callback or something like that.) Thanks ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
User parameter for SSL_set_verify
I have an unusual problem - I'm writing a connection server kind of application and to make a long story short, I have a number of pending outgoing ssl connections and I need to look at the certificate which each presents to determine how to handle the connection. With that in mind I use the SSL_set_verify() to set a callback to examine the presented certificate i.e. void SSL_set_verify(SSL *s, int mode, int (*verify_callback)(int, X509_STORE_CTX *)); Unfortunately there is no opportunity to provide a user argument to match up a presented certificate with its corresponding pending connection - the callback presents only the preverify result and the context store which I can use to retrieve the certificate. (For the incoming facing connection I used SSL_CTX_set_tlsext_servername_callback(..) for which SSL_CTX_set_tlsext_servername_arg(...) provides a user argument which works great.) Any suggestions on how to get around this problem? (Did I mention that I'm doing this in boost? That shouldn't have any bearing on the solution though.) --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: User parameter for SSL_set_verify
You're right about it being non-obvious but I got it working, thanks! ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: May 10, 2012 3:47 PM To: openssl-users@openssl.org Subject: Re: User parameter for SSL_set_verify On Thu, May 10, 2012, Nou Dadoun wrote: I have an unusual problem - I'm writing a connection server kind of application and to make a long story short, I have a number of pending outgoing ssl connections and I need to look at the certificate which each presents to determine how to handle the connection. With that in mind I use the SSL_set_verify() to set a callback to examine the presented certificate i.e. void SSL_set_verify(SSL *s, int mode, int (*verify_callback)(int, X509_STORE_CTX *)); Unfortunately there is no opportunity to provide a user argument to match up a presented certificate with its corresponding pending connection - the callback presents only the preverify result and the context store which I can use to retrieve the certificate. Actually there is a non obvious one through the OpenSSL ex_data mechanism. Certain structures can have user defined data attached to them. The SSL structure is one such example and X509_STORE_CTX another. In the cae of the X509_STORE_CTX the appropriate SSL structures is automatically passed via ex_data using the index returned by the function SSL_get_ex_data_X509_STORE_CTX_idx(). So using that you can get hold of the SSL structure and any data you want to place in there. There is an example in the SSL_CTX_set_verify() manual page. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Selecting certificate to be presented by a given endpoint in establishing an ssl connection
Quick question regarding certificate usage in an ssl connection; you can associate a number of certificates with a server endpoint - is there any way of deciding at runtime which certificate is presented to the client (depending on the identity of the client say). And would the same mechanism be usable for the certificate the client presents in the case of mutual authentication? (Pointers to documentation if any would be sufficient!) Thanks N --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: expired ssl certificate
I'm no ssl guru either but I'll make some brief comments and let others jump in
if I'm too far off the mark.
1. If you use the standard verify and the peer presents an expired
certificate, the certificate will not be verified and the connection will fail.
2. The verification callback is called after the regular verification is
performed, here's a simple example I posted with my own question yesterday:
static int verify_callback(int ok, X509_STORE_CTX *stor)
{
if(!ok)
{
printf(verify_callback Certificate Verification Error: %s\n,
X509_verify_cert_error_string(stor-error));
}
else
{
printf(verify_callback Certificate Verification Success\n);
}
return ok;
}
The ok parameter tells you whether the certificate passed so that if it's not
ok (didn't pass) you can examine the reason/error and the certificate itself to
see whether or not you want to over-rule that result. The return value
indicates whether you want to accept it or not - the above example only reports
the result (without changing it) and (if it fails) the reason for failure
without changing anything. If it's not ok and you look at the cert and it's
expired but you don't care, return 1 and it will be accepted. Look at the
examples in the pdf for some examples.
As I said earlier, standard warnings apply - you're overruling standard
security mechanisms for your own purposes which can be dangerous if you're not
careful.
3. I think I've answered that above N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Dinh, Thao V CIV NSWCDD, K72
Sent: April 11, 2012 4:19 AM
To: openssl-users@openssl.org
Subject: RE: expired ssl certificate
Hi Nou
Please help me understand more about this subject ( I am new to Openssl)
1. What happen if the peer presents an expired certificate and we do not
implement callback using SSL_CTX_set_verify with SSL_VERIFY_PEER flag set, will
the SSL_connect or SSL_accept fail ???
2. What is the function of verification callback ? Just report error of
expired certificate or actually let expired certificate be accepted ?? what is
X509_.. function shoud I uses to let expired cert being accept ??
3. what is the different between standard verify operation and the verify
callback ???
Thank You
Thao Dinh
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Nou Dadoun
Sent: Tuesday, April 10, 2012 3:15 PM
To: openssl-users@openssl.org
Subject: RE: expired ssl certificate
You can use a verification callback to look at the certificate after the
standard verify operation has been performed to decide whether or not to allow
the certificate anyway.
Look at the O'Reilly book
(http://doc.hackbbs.org/Reseaux/O_Reilly_-_Network_Security_with_OpenSSL.pdf )
page 132 or so has some sample code you can probably modify.
Standard warnings apply .. N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Srihari, Gautam
Sent: April 10, 2012 3:04 AM
To: openssl-...@openssl.org; openssl-users@openssl.org
Subject: expired ssl certificate
Hi,
I have a server application and the client uses https to connect
to the server. For this I had created an openssl self signed certificate
cacert.pem which has been distributed to all the client applications.
Now unfortunately the certificate has expired. I can create a new
certificate.
But distributing to all the clients is going to be difficult.
Is there some way by using open ssl, I can make the server ignore expired
certificates
so I don't have to ask each client to update to a new certificate?
The crux of the problem is that I want to continue to allow clients to use the
server without
Having them to upgrade anything i.e change should be done only on the server
side.
Reg.,
Gautam
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: openssl/crypto cleanup
Thanks for the note, seems like it's even more fundamental than that because
the unit test not only doesn't establish an ssl connection, it doesn't even use
an ssl context! As a certificate unit test, it's *only* testing our various
certificate deployment scenarios to make sure that we retrieve the right CA
certificate and do a verification correctly (we also do a test encrypt/decrypt
on the keys to make sure they're usable).
The spoiler crypto tests don't use an ssl context either (they're really just
using test encrypt/decrypts for the various algorithm deployments scenarios) so
it's still a little mysterious why the two would interfere with each other! It
would seem to be right down in the crypto algorithm code because that seems to
be all that they have in common. That's why a total scrub cleanup function
would be useful ... N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
-Original Message-
From: jeremy hunt [mailto:jere...@optimation.com.au]
Sent: April 10, 2012 6:11 PM
To: openssl-users@openssl.org
Cc: Nou Dadoun
Subject: Re: openssl/crypto cleanup
On a disconnect check the state of the SSL data structure and call
SSL_free if it is not null.
if (*sslptr != NULL) {
SSL_free (*sslptr);
*sslptr = NULL;
}
Though as you say it is a certificate issue, then perhaps you need to
look at
SSL_CTX_free(*sslctxptr)
Look at the man page for this. Perhaps you are reusing an SSL context
structure. We don't need to call this in our disconnect code, but
testing code may reuse a structure that running code doesn't.
If these don't work for you, then maybe you should look at putting in
some diagnostic printfs to look for where the dirty data is being kept,
you might be reusing something like a DH or X509 structure and you may
need to call a free or cleanup function for that particular structure.
I don't know about the callback function, but I like your guess.
Good Luck,
Jeremy
Nou Dadoun wrote:
Hi, I've looked at the archives and didn't see any apropos discussions
so I thought I'd go straight to the list:
We use the openssl crypto libraries in several places in our product
both in fips and non-fips modes.
We have a set of unit tests to exercise various portions of our code
to ensure that our implementations using these tools work the way that
they're supposed to.
I've run into an unusual problem, we have a set of crypto
(encrypt/decrypt) tests and a separate set of certificate tests (e.g.
retrieve a certificate and its CA and do a certificate verification).
If I run the certificate tests first and then the crypto tests, all
the tests pass and everything works great.
If I run the crypto tests first and then the certificate test, the
verification fails due to a signature failure. This implies to me
that the crypto tests are leaving something in the openssl/crypto
machinery in a funky state which breaks the subsequent certificate
signature computation.
A couple of questions:
What can I do to completely clean the openssl/crypto state to ensure
that this doesn't happen? I've added:
CRYPTO_cleanup_all_ex_data();
ENGINE_cleanup();
But this appears to be inadequate (I suspect necessary but
insufficient), any suggestions?
(I've reordered the tests so that they're passing now but I'd like to
avoid this hack if I can.)
Second question, I added a verification callback routine, e.g.
staticint verify_callback(int ok, X509_STORE_CTX *stor)
{
if(!ok)
{
printf(verify_callback Certificate Verification Error: %s\n,
X509_verify_cert_error_string(stor-error));
}
else
{
printf(verify_callback Certificate Verification Success\n);
}
return ok;
}
I've put a breakpoint in it and noticed that when verifying a
certificate, this callback is called twice,
In the successful order above (cert then crypto tests) both calls have
ok == 1,
In the unsuccessful order (crypto then cert), the first call is 1 and
the second is 0 with a signature error reported.
Why is it called twice and what's the difference? (I suspect the
second is signature checking and the first is everything else but I'm
curious).
Thanks in advance ... N
---
Nou Dadoun
ndadoun@teradici.com_
_604-628-1215
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: expired ssl certificate
You can use a verification callback to look at the certificate after the standard verify operation has been performed to decide whether or not to allow the certificate anyway. Look at the O'Reilly book (http://doc.hackbbs.org/Reseaux/O_Reilly_-_Network_Security_with_OpenSSL.pdf ) page 132 or so has some sample code you can probably modify. Standard warnings apply N --- Nou Dadoun ndad...@teradici.com 604-628-1215 From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Srihari, Gautam Sent: April 10, 2012 3:04 AM To: openssl-...@openssl.org; openssl-users@openssl.org Subject: expired ssl certificate Hi, I have a server application and the client uses https to connect to the server. For this I had created an openssl self signed certificate cacert.pem which has been distributed to all the client applications. Now unfortunately the certificate has expired. I can create a new certificate. But distributing to all the clients is going to be difficult. Is there some way by using open ssl, I can make the server ignore expired certificates so I don't have to ask each client to update to a new certificate? The crux of the problem is that I want to continue to allow clients to use the server without Having them to upgrade anything i.e change should be done only on the server side. Reg., Gautam
openssl/crypto cleanup
Hi, I've looked at the archives and didn't see any apropos discussions so I
thought I'd go straight to the list:
We use the openssl crypto libraries in several places in our product both in
fips and non-fips modes.
We have a set of unit tests to exercise various portions of our code to ensure
that our implementations using these tools work the way that they're supposed
to.
I've run into an unusual problem, we have a set of crypto (encrypt/decrypt)
tests and a separate set of certificate tests (e.g. retrieve a certificate and
its CA and do a certificate verification).
If I run the certificate tests first and then the crypto tests, all the tests
pass and everything works great.
If I run the crypto tests first and then the certificate test, the verification
fails due to a signature failure. This implies to me that the crypto tests
are leaving something in the openssl/crypto machinery in a funky state which
breaks the subsequent certificate signature computation.
A couple of questions:
What can I do to completely clean the openssl/crypto state to ensure that this
doesn't happen? I've added:
CRYPTO_cleanup_all_ex_data();
ENGINE_cleanup();
But this appears to be inadequate (I suspect necessary but insufficient), any
suggestions?
(I've reordered the tests so that they're passing now but I'd like to avoid
this hack if I can.)
Second question, I added a verification callback routine, e.g.
static int verify_callback(int ok, X509_STORE_CTX *stor)
{
if(!ok)
{
printf(verify_callback Certificate Verification Error: %s\n,
X509_verify_cert_error_string(stor-error));
}
else
{
printf(verify_callback Certificate Verification Success\n);
}
return ok;
}
I've put a breakpoint in it and noticed that when verifying a certificate, this
callback is called twice,
In the successful order above (cert then crypto tests) both calls have ok == 1,
In the unsuccessful order (crypto then cert), the first call is 1 and the
second is 0 with a signature error reported.
Why is it called twice and what's the difference? (I suspect the second is
signature checking and the first is everything else but I'm curious).
Thanks in advance ... N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
RE: OpenSSL Windows CryptoAPI certificate and encrypt/decrypt interop
I think I'll probably have to jump off that bridge when I get to it, but to make progress I'm going to try to get something going in the interim. I think I'll post some code (I suspect that the padding provided by the capi encrypt/decrypt is somehow different than what openssl is doing - the ms docs are woefully inadequate) but if anyone has pointers on information on how to use the capi engine, I'd greatly appreciate it, thanks! ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: March 8, 2012 1:55 PM To: openssl-users@openssl.org Subject: Re: OpenSSL Windows CryptoAPI certificate and encrypt/decrypt interop On Thu, Mar 08, 2012, Nou Dadoun wrote: Thanks for the response, I'm trying to allow end-users to use commercially purchased certificates so I'd rather not make the assumption that the key is exportable. Using the capi engine sounds like a viable alternative, but I've had trouble tracking down details on how to use it. Unfortunately I have a few restrictions; we're fips-certified on openssl 0.98n so that's the version I'm stuck with (without recertifying). I also want to use the crypto api directly to tell it which certificate to load and use (i.e. user configurable through a gpo setting) and then have the engine use that certificate for the ssl handshake to the peer. I've read the O'Reilly section on Engines but it's pretty rudimentary and doesn't touch the capi engine, do you have a pointer to any user documentation that might have some examples on using the capi engine? If you need all crypto to be FIPS compliant (for some value of compliant) that's a can of worms because the relevant CSPs might not be and you'd be mixing various cryptographic operations across boundaries. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL Windows CryptoAPI certificate and encrypt/decrypt interop
That does sound incredibly powerful (and right up the alley of what I'm try to do) but rather than peppering you with individual questions, is there any documentation other than tackling the code? (even an api man page wrt engine usage would help) E.g. I'd like to specify the location of the windows cert store to look in for the certificate that I want to use being selecting the actual certificate, and it's not clear how I would do that, thanks again for your help ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: March 9, 2012 10:11 AM To: openssl-users@openssl.org Subject: Re: OpenSSL Windows CryptoAPI certificate and encrypt/decrypt interop On Fri, Mar 09, 2012, Nou Dadoun wrote: I think I'll probably have to jump off that bridge when I get to it, but to make progress I'm going to try to get something going in the interim. I think I'll post some code (I suspect that the padding provided by the capi encrypt/decrypt is somehow different than what openssl is doing - the ms docs are woefully inadequate) but if anyone has pointers on information on how to use the capi engine, I'd greatly appreciate it, thanks! ... N You can actually use the capi ENGINE from the command line to perform private key operations. You specify -engine capi -inform/-keyform engine and the input key parameter can take several forms. The default is a string from the corresponding certificate DN so if it has CN=steve then steve would do. At an API level you use ENGINE_load_private_key(steve) which returns an EVP_PKEY structure which can then be used like any other private key. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Encrypting with openssl and decrypting with capi cryptdecrypt
So here's what I'm trying to do in a unit test, wiring in the method
replacement seems to work (i.e. my priv decrypt callback is called at the right
place) but the encrypt -- decrypt doesn't work in a unit test so it certainly
won't work there or anywhere else.
So I load the certificate and get key handles using capi, brief snippets:
result =CryptAcquireCertificatePrivateKey(
m_pccert_context,
CRYPT_ACQUIRE_COMPARE_KEY_FLAG,
NULL,
m_crypto_provider,
key_spec,
NULL);
...
// Get Private Key
result = CryptGetUserKey(
m_crypto_provider,
AT_KEYEXCHANGE,
m_cert_key_pair);
...
// Get the public key information for the certificate.
result = CryptImportPublicKeyInfo(
m_crypto_provider,
X509_ASN_ENCODING,
m_pccert_context-pCertInfo-SubjectPublicKeyInfo,
m_cert_public_key);
That all works since I can then (pub) encrypt and (priv) decrypt a sample
message in capi, I do some other sanity tests and get to my interop test, I
load the x509 certificate from the m_pccert_context, i.e.
BIO * input = BIO_new_mem_buf_fn (
(void*) m_pccert_context-pbCertEncoded,
(UINT32) m_pccert_context-cbCertEncoded);
m_x509_cert = d2i_X509_bio_fn(input, NULL);
and then pull the public key to encrypt:
EVP_PKEY *my_pkey = X509_get_pubkey_fn(m_x509_cert);
my_rsa_key-n = BN_dup_fn(my_pkey-pkey.rsa-n);
my_rsa_key-e = BN_dup_fn(my_pkey-pkey.rsa-e);
When I extract and print the modulus (i.e. the n) from both my_rsa_key and the
m_cert_public_key (exported as a PUBLICKEYBLOB), they're the same (but
reversed), so I proceed to encrypt my test message with openssl:
enc_mess_len = RSA_public_encrypt(
strlen(test_mess),
(unsigned char *) test_mess,
(unsigned char *) enc_mess,
my_rsa_key,
RSA_PKCS1_OAEP_PADDING);
And decrypt with capi:
if(!CryptDecrypt(
m_cert_key_pair, //__in HCRYPTKEY hKey,
NULL,//__in HCRYPTHASH hHash,
TRUE,//__in BOOL Final,
CRYPT_OAEP, //__in DWORD dwFlags,
(BYTE*) enc_mess,//__inout BYTE *pbData,
decrypted_len //__inout DWORD *pdwDataLen,
))
{
// Figure out what went wrong.
DWORD last_error= GetLastError();
return -1;
}
And it always fails with NTE_BAD_DATA. (I've eliminated some function wrappers
but this is basically it.) I've tried different padding schemes, e.g.
CRYPT_OAEP --- RSA_PKCS1_OAEP_PADDING
?? the default - RSA_PKCS1_PADDING
I've tried CRYPT_DECRYPT_RSA_NO_PADDING_CHECK (and get an NTE_BAD_FLAGS error)
thanks ms, I've tried reversing the encrypted buffer, all to no avail.
Am I missing something here? Thanks in advance N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Encrypting with openssl and decrypting with capi cryptdecrypt
Sorry I knew I'd forget something, I've put the my_rsa_key declaration and
initialization in the right place marked / here / ... N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Nou Dadoun
Sent: March 9, 2012 12:01 PM
To: openssl-users@openssl.org
Subject: Encrypting with openssl and decrypting with capi cryptdecrypt
So here's what I'm trying to do in a unit test, wiring in the method
replacement seems to work (i.e. my priv decrypt callback is called at the right
place) but the encrypt -- decrypt doesn't work in a unit test so it certainly
won't work there or anywhere else.
So I load the certificate and get key handles using capi, brief snippets:
result =CryptAcquireCertificatePrivateKey(
m_pccert_context,
CRYPT_ACQUIRE_COMPARE_KEY_FLAG,
NULL,
m_crypto_provider,
key_spec,
NULL);
...
// Get Private Key
result = CryptGetUserKey(
m_crypto_provider,
AT_KEYEXCHANGE,
m_cert_key_pair);
...
// Get the public key information for the certificate.
result = CryptImportPublicKeyInfo(
m_crypto_provider,
X509_ASN_ENCODING,
m_pccert_context-pCertInfo-SubjectPublicKeyInfo,
m_cert_public_key);
That all works since I can then (pub) encrypt and (priv) decrypt a sample
message in capi, I do some other sanity tests and get to my interop test, I
load the x509 certificate from the m_pccert_context, i.e.
BIO * input = BIO_new_mem_buf_fn (
(void*) m_pccert_context-pbCertEncoded,
(UINT32) m_pccert_context-cbCertEncoded);
m_x509_cert = d2i_X509_bio_fn(input, NULL);
and then pull the public key to encrypt: / here /
RSA* my_rsa_key = RSA_generate_key(1024, RSA_F4, NULL, NULL;
EVP_PKEY *my_pkey = X509_get_pubkey_fn(m_x509_cert);
my_rsa_key-n = BN_dup_fn(my_pkey-pkey.rsa-n);
my_rsa_key-e = BN_dup_fn(my_pkey-pkey.rsa-e);
When I extract and print the modulus (i.e. the n) from both my_rsa_key and the
m_cert_public_key (exported as a PUBLICKEYBLOB), they're the same (but
reversed), so I proceed to encrypt my test message with openssl:
enc_mess_len = RSA_public_encrypt(
strlen(test_mess),
(unsigned char *) test_mess,
(unsigned char *) enc_mess,
my_rsa_key,
RSA_PKCS1_OAEP_PADDING);
And decrypt with capi:
if(!CryptDecrypt(
m_cert_key_pair, //__in HCRYPTKEY hKey,
NULL,//__in HCRYPTHASH hHash,
TRUE,//__in BOOL Final,
CRYPT_OAEP, //__in DWORD dwFlags,
(BYTE*) enc_mess,//__inout BYTE *pbData,
decrypted_len //__inout DWORD *pdwDataLen,
))
{
// Figure out what went wrong.
DWORD last_error= GetLastError();
return -1;
}
And it always fails with NTE_BAD_DATA. (I've eliminated some function wrappers
but this is basically it.) I've tried different padding schemes, e.g.
CRYPT_OAEP --- RSA_PKCS1_OAEP_PADDING
?? the default - RSA_PKCS1_PADDING
I've tried CRYPT_DECRYPT_RSA_NO_PADDING_CHECK (and get an NTE_BAD_FLAGS error)
thanks ms, I've tried reversing the encrypted buffer, all to no avail.
Am I missing something here? Thanks in advance N
---
Nou Dadoun
ndad...@teradici.com
604-628-1215
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: OpenSSL Windows CryptoAPI certificate and encrypt/decrypt interop
Thanks for the response, I'm trying to allow end-users to use commercially purchased certificates so I'd rather not make the assumption that the key is exportable. Using the capi engine sounds like a viable alternative, but I've had trouble tracking down details on how to use it. Unfortunately I have a few restrictions; we're fips-certified on openssl 0.98n so that's the version I'm stuck with (without recertifying). I also want to use the crypto api directly to tell it which certificate to load and use (i.e. user configurable through a gpo setting) and then have the engine use that certificate for the ssl handshake to the peer. I've read the O'Reilly section on Engines but it's pretty rudimentary and doesn't touch the capi engine, do you have a pointer to any user documentation that might have some examples on using the capi engine? Thanks again ... N --- Nou Dadoun ndad...@teradici.com 604-628-1215 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: March 7, 2012 5:52 PM To: openssl-users@openssl.org Subject: Re: OpenSSL Windows CryptoAPI certificate and encrypt/decrypt interop On Wed, Mar 07, 2012, Nou Dadoun wrote: I'm trying to develop a package which can establish an ssl connection between a windows server and a client using openssl and I'm running into some serious road blocks - I'm a relative novice at both the openssl and wincrypt apis, I've done extensive searching for any hints at how this problem might be solved but I haven't found anything similar which might be applicable. Here's a high-level description: On the server side, I'm using both openssl and the windows crypto api, I use the windows crypto api to access the windows certificate store and search for and load the certificate (with its private key) that I'm interested in using. I spent some time trying to extract the private key to use in openssl directly but discovered that the windows crypto api refuses to let go of it in a form that openssl can use directly. So I'm using the openssl RSA_set_method facility to replace the private key decrypt method (rsa_priv_dec) to pass off the heavy lifting to the cryptoapi (this seems like a reasonable thing to do and the kind of thing that would be done with a smart card or TCM or something where there's no direct access to the private key). I tell openssl to use the x509 encoding of the loaded certificate for incoming connections and wait. When a client SSL HELLO comes in, the server presents the x509 certificate, the client uses the public key in the certificate to encrypt its secret and sends the response to the server to decrypt with the private key. The server receives the response, my replaced method kicks in and tries to decrypt the 128-byte response using CryptDecrypt with the private key and fails with NTE_BAD_DATA (pretty opaque and not very informative). So the connection fails. I've done some unit testing on the api's and I can encrypt/decrypt sample messages using CryptEncrypt and CryptDecrypt, but anything that I've encrypted with RSA_public_encrypt gives me the same NTE_BAD_DATA error when I hand it to (private key) CryptDecrypt. I've extracted the PUBLICKEYBLOB to get the windows representation of the public key and I can see that the key bytes are in reverse order of the public key portion of the x509 certificate. I've read that the crypto api uses little-endian as opposed to everybody else's big-endian but (perhaps foolishly) assumed that that difference was only an internal representation issue, that something encrypted by openssl should be decryptable by CryptoAPI (I tried reversing the bytes of the encrypted message too and that didn't work.) So I'm a little stymied, am I missing some secret sauce somewhere? If openssl had an api to load certificates from windows cert stores that would be an alternate route but it seems as though this mechanism of using CryptoApi to handle the certificate access/management shouldn't be as difficult as it seems. And surely the interop problem I'm experiencing can't be unique to my setup. Anyone have any suggestions? I can post code on request but thought I'd start with a high-level description of the problem to avoid clouding the issue too much. If windows can export the key and certificate as a PKCS#12 (PFX) file you can use that with OpenSSL. If the key is unexportable you can't. OpenSSL has a CryptoAPI ENGINE you can use and that will handle the conversion between formats for you. It is supported on the command line which you can use as a test. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User
OpenSSL Windows CryptoAPI certificate and encrypt/decrypt interop
I'm trying to develop a package which can establish an ssl connection between a windows server and a client using openssl and I'm running into some serious road blocks - I'm a relative novice at both the openssl and wincrypt apis, I've done extensive searching for any hints at how this problem might be solved but I haven't found anything similar which might be applicable. Here's a high-level description: On the server side, I'm using both openssl and the windows crypto api, I use the windows crypto api to access the windows certificate store and search for and load the certificate (with its private key) that I'm interested in using. I spent some time trying to extract the private key to use in openssl directly but discovered that the windows crypto api refuses to let go of it in a form that openssl can use directly. So I'm using the openssl RSA_set_method facility to replace the private key decrypt method (rsa_priv_dec) to pass off the heavy lifting to the cryptoapi (this seems like a reasonable thing to do and the kind of thing that would be done with a smart card or TCM or something where there's no direct access to the private key). I tell openssl to use the x509 encoding of the loaded certificate for incoming connections and wait. When a client SSL HELLO comes in, the server presents the x509 certificate, the client uses the public key in the certificate to encrypt its secret and sends the response to the server to decrypt with the private key. The server receives the response, my replaced method kicks in and tries to decrypt the 128-byte response using CryptDecrypt with the private key and fails with NTE_BAD_DATA (pretty opaque and not very informative). So the connection fails. I've done some unit testing on the api's and I can encrypt/decrypt sample messages using CryptEncrypt and CryptDecrypt, but anything that I've encrypted with RSA_public_encrypt gives me the same NTE_BAD_DATA error when I hand it to (private key) CryptDecrypt. I've extracted the PUBLICKEYBLOB to get the windows representation of the public key and I can see that the key bytes are in reverse order of the public key portion of the x509 certificate. I've read that the crypto api uses little-endian as opposed to everybody else's big-endian but (perhaps foolishly) assumed that that difference was only an internal representation issue, that something encrypted by openssl should be decryptable by CryptoAPI (I tried reversing the bytes of the encrypted message too and that didn't work.) So I'm a little stymied, am I missing some secret sauce somewhere? If openssl had an api to load certificates from windows cert stores that would be an alternate route but it seems as though this mechanism of using CryptoApi to handle the certificate access/management shouldn't be as difficult as it seems. And surely the interop problem I'm experiencing can't be unique to my setup. Anyone have any suggestions? I can post code on request but thought I'd start with a high-level description of the problem to avoid clouding the issue too much. thanks in advance ... Nou --- Nou Dadoun ndad...@teradici.com 604-628-1215 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
