[openssl-users] openssl-1.1.0 sha1 performance
Afternoon, I have been running some speed tests of openssl 1.0.1, 1.0.2 and 1.1.0 versions against various compiler optimisations. Special interest was given to the more commonly used primitives, rsa's, aes's etc. I noticed that SHA1's have some significant performance improvements. However the multiplier by which it improved by diminishes as you approach 8k/16k block sizes. Any ideas why this tails off? I noticed no other 'statistically significant' change in other primitives, although freely admit i have not exhaustively checked. openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 16 size blocks: 9225205 sha1's in 3.00s openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 64 size blocks: 7275849 sha1's in 3.00s openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 256 size blocks: 4821329 sha1's in 3.00s openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 1024 size blocks: 2059373 sha1's in 3.00s openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 8192 size blocks: 327032 sha1's in 3.00s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 16 size blocks: 23362218 sha1's in 3.00s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 64 size blocks: 14131714 sha1's in 2.99s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 256 size blocks: 7166139 sha1's in 3.00s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 1024 size blocks: 2413233 sha1's in 3.00s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 8192 size blocks: 335803 sha1's in 3.00s openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 16384 size blocks: 169210 sha1's in 3.00s I assume the positive change was part of: *) Extensive assembler packs updates, most notably: - x86[_64]: AES-NI, PCLMULQDQ, RDRAND support; - x86[_64]: SSSE3 support (SHA1, vector-permutation AES); - x86_64: bit-sliced AES implementation; - ARM: NEON support, contemporary platforms optimizations; - s390x:z196 support; - *:GHASH and GF(2^m) multiplication implementations; [Andy Polyakov] Has anyone else completed any similar tests? Thank you, CraigT -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] 1.1.0-pre4: openssl speed chacha
Hi there, I don't seem to be able to benchmark chacha, nor does it appear in the list when I test all. Is this expected? I can see it in 'openssl ciphers -V "ALL"' and also negotiate from a client. Thanks CraigT -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
How is MD5 fingerprint on X509 created?
Hello, I am able to generate an MD5 fingerprint with the following command. openssl x509 -in user.pem -fingerprint -md5 -noout This fingerprint matches the fingerprint displayed by Thunderbird/Firefox. I am trying to generate an MD5 using a hash function in PHP, http://nl2.php.net/manual/en/function.openssl-digest.php The results I am getting from the PHP function are not the same as using the other methods. I'm sure I'm not putting the right data into the hash function. Should I be hashing the entire contents of the PEM file, only part, or is there additional data I need to add? Thank you, Matt
Re: How is MD5 fingerprint on X509 created?
Thank you Erik and Wim, that's exactly the information I needed! On Tue, Apr 19, 2011 at 2:27 PM, Wim Lewis wrote: > > On 19 Apr 2011, at 10:55 AM, Matt C wrote: > > Should I be hashing the entire contents of the PEM file, only part, or is > there additional data I need to add? > > The fingerprint that openssl computes is the hash of the entire certificate > in DER format. You should be able to recover the DER-formatted certificate > by base64-decoding the block of text between the BEGIN/END lines in the > PEM-formatted certifcate. > > There are other hashes of various parts of the certificate, used for other > things, but if you're trying to duplicate what openssl -fingerprint is > doing, that's how. > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Date format for X.509 certificate
I've extracted a date from a public certificate using the PHP command openssl_x509_parse. The date looks like this: 110419141516Z Can someone tell me how to make sense of this date (in PHP if possible). Thank you! Matt
Re: Date format for X.509 certificate
That's simple. Thank you again Erik. On Tue, Apr 19, 2011 at 5:22 PM, Erik Tkal wrote: > 110419141516Z = 2011 04(April) 19th 14:15:16Z(UTC) > > > > *Erik Tkal** > *Juniper OAC/UAC/Pulse Development > > > > *From:* owner-openssl-us...@openssl.org [mailto: > owner-openssl-us...@openssl.org] *On Behalf Of *Matt C > *Sent:* Tuesday, April 19, 2011 5:19 PM > *To:* openssl-users@openssl.org > *Subject:* Date format for X.509 certificate > > > > I've extracted a date from a public certificate using the PHP command > openssl_x509_parse. > > > > The date looks like this: 110419141516Z > > > > Can someone tell me how to make sense of this date (in PHP if possible). > > > > Thank you! > > > > Matt >
Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
Hi, We are implementing multi-layer support for our openssl-based PKI solution and had the following query: Currently our PKI solution supports only single layer CA support and we use SSL_CTX_load_verify_locations API with the CAFile option, meaning that the service loads the CA certificate from a PEM file. When testing multi-layer support between a client-server model with *SSL_VERIFY_PEER *set to true, we observed that using the CAFile(with all CA certificates- root + intermediate concatenated into a single PEM file) does not work anymore. But using CAPath option (storing each CA in separate file, creating hashes for them in a directory and providing that directory in CAPath) seems to work fine. Is this a known bug with openSSL or is it something that we are doing wrong.* * Also, from the openSSL community perspective, is it advisable to use CAFile option or CAPath option when providing multi-layer support? Regds, Ashok
RE: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
Hi, One more question here: In case of a server application, it is expected to send the intermediate certificates to the client. And in this case, is this API -- SSL_CTX_load_verify_locations() sufficient to be used? Or is there a separate API to send the intermediate CA certificates across to the client? P.S. My previous query also is unanswered. It would be great if I get some responses to that also ;) Regds, Ashok -- Forwarded message -- From: Ashok C Date: Wed, Nov 23, 2011 at 12:55 PM Subject: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg. To: openssl-users@openssl.org Hi, We are implementing multi-layer support for our openssl-based PKI solution and had the following query: Currently our PKI solution supports only single layer CA support and we use SSL_CTX_load_verify_locations API with the CAFile option, meaning that the service loads the CA certificate from a PEM file. When testing multi-layer support between a client-server model with *SSL_VERIFY_PEER *set to true, we observed that using the CAFile(with all CA certificates- root + intermediate concatenated into a single PEM file) does not work anymore. But using CAPath option (storing each CA in separate file, creating hashes for them in a directory and providing that directory in CAPath) seems to work fine. Is this a known bug with openSSL or is it something that we are doing wrong.* * Also, from the openSSL community perspective, is it advisable to use CAFile option or CAPath option when providing multi-layer support? Regds, Ashok
Re: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
Hi Dave, Thanks for the reply. Some more followup questions here: In case of a server application, it is expected to send > the intermediate certificates to the client. And in this case, > is this API -- SSL_CTX_load_verify_locations( ) sufficient to be used? > Or is there a separate API to send the intermediate CA certificates > across to the client? >>>No, certs to *send* are separate from verifying *received*. >>>Yes, SSL_CTX_user_certificate_ > > >>>chain_file or SSL_CTX_add_extra_chain_cert . So, in this case certificates to be "sent" need to sent only using the use_certificate* APIs., among which none of them take CAPath as an input. In this case, how does the s_server/s_client implementation work with -CAPath options? Internally does it use just load_verify_locations(*,CAPath) ? Or does it translate the hashes present in CAPath to X509 objects and then use the use_certificate* APIs? To be more clear, is there any option in which we can use CAPath to "send" certificates? >>1. I doubt there's a bug in OpenSSL here; this is very widely >>used functionality; both CAfile and CApath have worked for me >>in all versions I've used. What version(s) are you running, >>is it vanilla build or any mods/patches, and built how? We are running openssl-0.9.8g and 1.0.0d in normal x86/x86_64 environment with few CVE patches. On Tue, Nov 29, 2011 at 9:51 AM, Dave Thompson wrote: > > From: owner-openssl-us...@openssl.org On Behalf Of Ashok C > > Sent: Monday, 28 November, 2011 00:35 > > > One more question here: > > In case of a server application, it is expected to send > > the intermediate certificates to the client. And in this case, > > is this API -- SSL_CTX_load_verify_locations() sufficient to be used? > > Or is there a separate API to send the intermediate CA certificates > > across to the client? > > No, certs to *send* are separate from verifying *received*. > > Yes, SSL_CTX_user_certificate_chain_file or SSL_CTX_add_extra_chain_cert . > > Similar but less obvious, if you use client auth (i.e. client > presents cert) the CA name(s) "requested" in the CertRequest > are separate from the CA cert(s) actually used for verification. > Often you want to make these the same, but it's not automatic. > Use SSL_[CTX_]set_client_CA_list or SSL_[CTX_]add_client_CA . > > > P.S. My previous query also is unanswered. It would be great > > if I get some responses to that also ;) > > > From: Ashok C > > Date: Wed, Nov 23, 2011 at 12:55 PM > > > We are implementing multi-layer support for our openssl-based > > PKI solution and had the following query: > > The usual term for what I think you mean is multi-LEVEL CAs, > or hierarchical CAs. > > > Currently our PKI solution supports only single layer CA support > > and we use SSL_CTX_load_verify_locations API with the CAFile option, > > meaning that the service loads the CA certificate from a PEM file. > > When testing multi-layer support between a client-server model > > with SSL_VERIFY_PEER set to true, we observed that using the CAFile > > (with all CA certificates- root + intermediate concatenated into > > a single PEM file) does not work anymore. But using CAPath option > > (storing each CA in separate file, creating hashes for them in a > > directory and providing that directory in CAPath) seems to work fine. > > Is this a known bug with openSSL or is it something that we are doing > wrong. > > 1. I doubt there's a bug in OpenSSL here; this is very widely > used functionality; both CAfile and CApath have worked for me > in all versions I've used. What version(s) are you running, > is it vanilla build or any mods/patches, and built how? > > 2. What exactly are you testing, and what exactly is the error(s)? > Can you reproduce it with commandline s_client and/or s_server? > > 3. For SSL/TLS it is common, but not universal, for the server to > provide in its handshake all intermediate CA certs, and similarly > for the client to do so if client-auth is used. If all peers of a > relier do this it doesn't need to configure any intermediate certs, > only the root(s). This is often more convenient, since for (some? > many?) public CAs the intermediates tend to change more often, and > the entity that gets a cert from the CA may be the first to know. > You don't say if your 'solution' uses public CAs or your own CA(s); > if the latter presumably the behavior is more under your control. > > If you are using OpenSSL cert verification (and perhaps other functions) > for some other protocol/application/whatever, ans
Re: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
Hi Dave, Keeping the things you have mentioned in mind, this is how it goes. In server side, EE key is loaded using SSL_CTX_use_RSAPrivateKey_file(ctx,eekeyfile,SSL_FILETYPE_PEM); EE certificate is loaded using SSL_CTX_use_certificate_file(ctx, eepemfile,SSL_FILETYPE_PEM); And the intermediate certificate chain is loaded using SSL_CTX_use_certificate_chain_file(ctx, interchain) - This chain contains intermediate CA certs without the rootCA. In client side, rootCA is loaded using SSL_CTX_load_verify_locations(ctx,capemfile,NULL). After attempting SSL_connect from client, the intermediate certificate chain and the EE certificate are received in client side using SSL_get_peer_cert_chain(ssl) and SSL_get_peer_certificate (ssl) respectively. After this we call SSL_get_verify_result(ssl) which fails. So question here is that whether we need to add the received chain explicitly to the verify locations in client side? Meaning, do we need to build the chain from client side explicitly by ourselves? Regds, Ashok On Fri, Dec 2, 2011 at 5:33 AM, Dave Thompson wrote: > > From: owner-openssl-us...@openssl.org On Behalf Of Ashok C > > Sent: Wednesday, 30 November, 2011 00:51 > > > Some more followup questions here: > > In case of a server application, it is expected to send > > > the intermediate certificates to the client. And in this case, > > > is this API -- SSL_CTX_load_verify_locations( > > ) sufficient to be used? > > > Or is there a separate API to send the intermediate CA > certificates > > > across to the client? > > > >>>No, certs to *send* are separate from verifying *received*. > > > >>>Yes, SSL_CTX_user_certificate_chain_file or > SSL_CTX_add_extra_chain_cert . > > > So, in this case certificates to be "sent" need to sent only > > using the use_certificate* APIs., among which none of them take > > CAPath as an input. > > That's not what I said. _use_certificate[_ASN1|file] > (but NOT _use_certificate_chain_file) is used to provide > an entity's own certificate. It is always sent if > authentication is used for this entity in the handshake > (for server usually, for client sometimes). > > _use_certificate_chain_file (not 'user', my typo, sorry) > or _add_extra_chain_cert may be used to specify chain > or intermediate certs. They are added to the Cert message > if authentication is used for this entity. > > > In this case, how does the s_server/s_client implementation > > work with -CAPath options? Internally does it use just > > load_verify_locations(*,CAPath) ? Or does it translate > > the hashes present in CAPath to X509 objects and then > > use the use_certificate* APIs? > > s_server and s_client call _load_verify_locations, which uses > CAfile and/or CApath to verify subsequently received cert(s). > It does NOT use them as own (entity) or chain certs. > > > To be more clear, is there any option in which we can use > > CAPath to "send" certificates? > > No. CApath within OpenSSL is only used for verifying received cert(s). > > s_server and s_client do not have any feature to send chain certs. > They are only test/sample programs; if you want something different, > use your own program (perhaps based on them, if you wish). > > > >>1. I doubt there's a bug in OpenSSL here; this is very widely > > >>used functionality; both CAfile and CApath have worked for me > > >>in all versions I've used. What version(s) are you running, > > >>is it vanilla build or any mods/patches, and built how? > > > We are running openssl-0.9.8g and 1.0.0d in normal x86/x86_64 > > environment with few CVE patches. > > I still have 0.9.8g builds (and other 0.9.8) around for support. > On Solaris/sparc, Linux/x86, and Windows/x86 both CAfile and CApath > work equivalently and as expected. 1.0.0c also works on all, > and 1.0.0e on the first two (haven't done 1.0.0e on Windows > because no longer needed on the systems I support). > I don't do specific x86_64 builds, we just run x86 code on those > machines, but I can't imagine this would be an ISA-dependent bug. > (As opposed to some crypto primitives like AES and SHA1, which do > have different assembly code -- but are also very well tested.) > > As I asked before, can you reproduce with s_server and s_client? > If so, post exact files (using a throwaway key) and we can > try to look at it (although the X509-store/lookup stuff is > in my opinion among the most confusing part of OpenSSL code). > > If it only occurs in your program(s), I suspect y
Re: Usage of CAPath/CAFile options in int SSL_CTX_load_verify_locations Reg.
Hi Dave, >>But even with that done/fixed in my test environment I DO get >>verify error 24 invalid CA cert depth 1 (my only intermediate). >>Is that what you're getting? If so, it looks like maybe the >>'purpose' checks have been made stricter since the last time >>I did this in test, where I have V1/noextension certs. >>I can't set up a test with real(er) (CA)certs immediately. >>If you have V1 or otherwise 'substandard' CA certs, you might >>try enhancing those. Yes, I was getting the same error. And after using v3 certificates, the error did not appear again and my client-server app is working well with the multi-level configuration. Thanks a lot for your patient help in this regard. Regds, Ashok On Sat, Dec 3, 2011 at 4:17 AM, Dave Thompson wrote: > > From: Ashok C [mailto:ash@gmail.com] > > Sent: Friday, 02 December, 2011 00:11 > > > Keeping the things you have mentioned in mind, this is how it goes. > > In server side, EE key is loaded using > > SSL_CTX_use_RSAPrivateKey_file(ctx,eekeyfile,SSL_FILETYPE_PEM); > > EE certificate is loaded using SSL_CTX_use_certificate_file(ctx, > > eepemfile,SSL_FILETYPE_PEM); > > And the intermediate certificate chain is loaded using > > SSL_CTX_use_certificate_chain_file(ctx, interchain) - This chain > > contains intermediate CA certs without the rootCA. > > In client side, rootCA is loaded using > > SSL_CTX_load_verify_locations(ctx,capemfile,NULL). > > After attempting SSL_connect from client, the intermediate > certificate > > chain and the EE certificate are received in client side using > > SSL_get_peer_cert_chain(ssl) and SSL_get_peer_certificate (ssl) > respectively. > > After this we call SSL_get_verify_result(ssl) which fails. > > So question here is that whether we need to add the received > > chain explicitly to the verify locations in client side? Meaning, > > do we need to build the chain from client side explicitly by ourselves? > > First, I made a mistake; it's been a long time since I coded this. > CTX_use_certificate_chain_file loads BOTH the entity cert (which > must be first in the file) AND the chain certs, and thus REPLACES > CTX_use_certificate_file. I'm guessing you have that data, > since if _use_certificate_chain_ doesn't contain the EE cert > then handshake can't select this auth type (and we have no other) > which produces a rather different (and less helpful!) error. > > But even with that done/fixed in my test environment I DO get > verify error 24 invalid CA cert depth 1 (my only intermediate). > Is that what you're getting? If so, it looks like maybe the > 'purpose' checks have been made stricter since the last time > I did this in test, where I have V1/noextension certs. > I can't set up a test with real(er) (CA)certs immediately. > If you have V1 or otherwise 'substandard' CA certs, you might > try enhancing those. > > These specific checks appear to be bypassed for certs in the > truststore, so putting all of the chain above the server EE > in the client truststore is an alternative (and works for me). > In that case the server only needs to send its EE cert (i.e. > only _use_certificate). This is typically more work to set up > and manage 'in the wild', but it is an alternative. > >
Supporting oldwithold, newwithnew CA certificates Reg.
Hi, What will be the recommendation from the open source community for supporting the following scenario in a openSSL based client/server application: *The certificates involved:* old CA certificate of the CA authority(root) new CA certificate of the CA authority(root) Server's end entity certificate issued by the old CA certificate, Server's end entity certificate issued by the new CA certificate Client's end entity certificate issued by the new CA certificate SSL_VERIFY_PEER set to TRUE. i.e., Client verifies server certificate and server verifies client certificate. *Scenario:* Now, the client in its SSL_load_verify_locations() will need to load both the old CA certificate as well as the new CA certificate. This will be to make sure that the connection is successful when the server sends the new end entity certificate or even when the server sends its old EE certificate(No CRLs involved as of now). So, now it is like loading multiple trust anchors in a single file. So here, is it better to use the CAFile option to load the CA certificates for verification(putting both the old CA certificate + new CA certificate into a single concatenated PEM file(CAFile)) or is it better to use the CAPath option for this scenario: Generating hashes for old CA certificate and new CA certificate separately and putting them into one common directory(CAPath)? Basically we wanted to know if CAFile would give a problem in case of multiple trust anchor certificates put together? Regds, Ashok
Re: Supporting oldwithold, newwithnew CA certificates Reg.
Thanks Dave. That part of it is clear now. Another doubt I have is about the SSL_CTX_set_client_ca_list and the SSL_get_client_ca_list. I understand that the set method is called by the server to set the list of CA names that it actually expects from the client. And the client calls ssl_get_client_ca_list to get these names and send the appropriate CA certificates in its chain for verification to the server. I assume that both these methods are actually optional even when SSL_VERIFY_PEER flag is set to true, i.e., client verifies server and server verifies client. I set up my server and client without these two methods and things still go fine. What would be the exact purpose of this family of methods? What I understand from my reading is that the SSL_CTX_set_client_CA_list function is only needed by server applications that verify the identity of remote client applications when SSL sessions are started and that if the SSL_CTX_set_client_CA_list function is not used and you request a client certificate, the list of CA names that get passed to the client application are the CAs from the SSL_CTX_load_verify_locations function. Is my understanding correct? Regds, Ashok On Wed, Dec 21, 2011 at 8:46 AM, Dave Thompson wrote: > > From: owner-openssl-us...@openssl.org On Behalf Of Ashok C > > Sent: Tuesday, 20 December, 2011 04:16 > > > What will be the recommendation from the open source community for > > supporting the following scenario in a openSSL based client/server > application: > > > The certificates involved: > > old CA certificate of the CA authority(root) > > new CA certificate of the CA authority(root) > > Server's end entity certificate issued by the old CA certificate, > > Server's end entity certificate issued by the new CA certificate > > Client's end entity certificate issued by the new CA certificate > > SSL_VERIFY_PEER set to TRUE. i.e., Client verifies server > certificate > > and server verifies client certificate. > > Note: in client SSL_VERIFY_PEER fails if server cert doesn't verify; > in server it requests cert from client, and fails if client cert > is provided and doesn't verify, but succeeds if client doesn't provide > cert. To fail in the latter case, add SSL_VERIFY_FAIL_IF_NO_PEER_CERT. > Or else after the handshake explicitly check SSL_get_peer_certificate > and if missing do some appropriate error. > > Important note: make sure the old and new root certs have different > names. (Same for intermediate CAs, which your example doesn't have.) > OpenSSL looks-up using Issuer name only. It *verifies* AKI if present, > and of course uses subjectkey to verify child and thus gets an error > if lookup found wrong parent. But it looks-up only by name, so if > old and new certs have the same name OpenSSL may use the wrong one. > > > Scenario: > > Now, the client in its SSL_load_verify_locations() will need to > > load both the old CA certificate as well as the new CA certificate. > > > So, now it is like loading multiple trust anchors in a single file. > > So here, is it better to use the CAFile option to load [] a single > > concatenated PEM file(CAFile)) or is it better to use the CAPath option > > for this scenario: [with hashnames] > > Either. Whichever you or your users prefer. > > Usual caveat: the CApath hash changed between 0.9.8 and 1.0.0. > Make sure to use the correct one for the code you run. > > Rarer caveat: CApath can be updated while a program using it is > running; generally this only matters for a (very) long-running > server. CAfile ignores updates, unless you re-load explicitly. > > > Basically we wanted to know if CAFile would give a problem > > in case of multiple trust anchor certificates put together? > > No problem; that's quite normal. The truststore, either CAfile > or CApath or a combination, exists to contain all trusted roots > and usually (though not always) there are multiple roots. > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Re: Supporting oldwithold, newwithnew CA certificates Reg.
Sorry for spamming, a small correction here. Scenario 3 is also failing and not successful as indicated in my earlier email. *Scenario 3:* openssl s_server -cert neweecert.pem -key neweekey.pem openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem Result: Connection failure. Regds, Ashok On Tue, Dec 27, 2011 at 4:50 PM, Ashok C wrote: > Thanks Dave. > But regarding this: > > >>Important note: make sure the old and new root certs have different > names. (Same for intermediate CAs, which your example doesn't have.) > OpenSSL looks-up using Issuer name only. It *verifies* AKI if present, > and of course uses subjectkey to verify child and thus gets an error > if lookup found wrong parent. But it looks-up only by name, so if > old and new certs have the same name OpenSSL may use the wrong one. > >> > > > I actually tested this particular scenario in my testbed and found that it > is not necessary that the old and new CA certs have different names. > I generated an oldcacert.pem and and oldcakey.pem using which I signed my > oldeecert.pem. Similarly, I generated an newcacert.pem and a newcakey.pem > using which I signed my neweecert.pem. Both oldcacert.pem and newcacert.pem > had the same subject/issuer names. The scenarios I tested go below: > *Scenario 1:* > openssl s_server -cert oldeecert.pem -key oldeekey.pem > openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem > Result: Connection successful > > *Scenario 2:* > openssl s_server -cert neweecert.pem -key neweekey.pem > openssl s_client -CAfile /root/certs/cacerts/newcacert.pem > Result:Connection successful > > *Scenario 3:* > openssl s_server -cert neweecert.pem -key neweekey.pem > openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem > Result: Connection successful > * > Scenario 4:* > openssl s_server -cert oldeecert.pem -key oldeekey.pem > openssl s_client -CAfile /root/certs/cacerts/newcacert.pem > Result: Connection Failure > > Now, I put both oldcacert.pem and newcacert.pem into a single > combined.pem, the first certificate being oldcacert.pem and the second > certificate being newcacert.pem. > > *Scenario 5:* > openssl s_server -cert oldeecert.pem -key oldeekey.pem > openssl s_client -CAfile /root/certs/cacerts/combined.pem > Result: Connection Successful > > *Scenario 6:* > openssl s_server -cert neweecert.pem -key neweekey.pem > openssl s_client -CAfile /root/certs/cacerts/combined.pem > Result: Connection Successful > > So now, this means that the openSSL verification check does not stop with > the first matching issuer certificate alone right? Because if that was the > case, Scenario 6 should have failed. > I have attached my certificates for reference. All are v3 certificates. > I am using openssl version "openssl-0.9.8g". > > One more clarification: > > >>If OpenSSL client has cert-and-pkey configured and receives CertReq, > it sends that cert regardless of any CAlist the server asked for; > that cert may be accepted or not depending on the server. And if > callback or engine is used it appears (but I haven't tested) that > can similarly select any cert regardless of what the server asked. > >> > > > Are you indicating here that the client can have multiple end entity > certificates? Till now I had the assumption that the server/client can have > only a single end entity certificate. Also, if the server can ask client to > send selective certificates, wouldn't it be applicable that the client also > can request the server for specific certificates? Are there separate > openSSL APIs for this or we have to use the same family of > ssl_ctx_set_client* family of APIs for this purpose also? > > Regds, > Ashok > > > > > > > > On Sat, Dec 24, 2011 at 3:19 AM, Dave Thompson wrote: > >> > From: owner-openssl-us...@openssl.org On Behalf Of Ashok C >> > Sent: Thursday, 22 December, 2011 10:55 >> >> > Another doubt I have is about the SSL_CTX_set_client_ca_list >> > and the SSL_get_client_ca_list. >> >> > I understand that the set method is called by the server to >> > set the list of CA names that it actually expects from the client. >> > And the client calls ssl_get_client_ca_list to get these names and >> > send the appropriate CA certificates in its chain for verification >> > to the server. >> >> Nit: case is important in C identifiers. Skipping that: >> >> Not quite. Server can call _set_client_CA_list to set the CA names it >> *asks for* from the client; server still uses _load_verify_locations >> to verify the ce
Re: Supporting oldwithold, newwithnew CA certificates Reg.
Thanks Dave. But regarding this: >>Important note: make sure the old and new root certs have different names. (Same for intermediate CAs, which your example doesn't have.) OpenSSL looks-up using Issuer name only. It *verifies* AKI if present, and of course uses subjectkey to verify child and thus gets an error if lookup found wrong parent. But it looks-up only by name, so if old and new certs have the same name OpenSSL may use the wrong one. >> I actually tested this particular scenario in my testbed and found that it is not necessary that the old and new CA certs have different names. I generated an oldcacert.pem and and oldcakey.pem using which I signed my oldeecert.pem. Similarly, I generated an newcacert.pem and a newcakey.pem using which I signed my neweecert.pem. Both oldcacert.pem and newcacert.pem had the same subject/issuer names. The scenarios I tested go below: *Scenario 1:* openssl s_server -cert oldeecert.pem -key oldeekey.pem openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem Result: Connection successful *Scenario 2:* openssl s_server -cert neweecert.pem -key neweekey.pem openssl s_client -CAfile /root/certs/cacerts/newcacert.pem Result:Connection successful *Scenario 3:* openssl s_server -cert neweecert.pem -key neweekey.pem openssl s_client -CAfile /root/certs/cacerts/oldcacert.pem Result: Connection successful * Scenario 4:* openssl s_server -cert oldeecert.pem -key oldeekey.pem openssl s_client -CAfile /root/certs/cacerts/newcacert.pem Result: Connection Failure Now, I put both oldcacert.pem and newcacert.pem into a single combined.pem, the first certificate being oldcacert.pem and the second certificate being newcacert.pem. *Scenario 5:* openssl s_server -cert oldeecert.pem -key oldeekey.pem openssl s_client -CAfile /root/certs/cacerts/combined.pem Result: Connection Successful *Scenario 6:* openssl s_server -cert neweecert.pem -key neweekey.pem openssl s_client -CAfile /root/certs/cacerts/combined.pem Result: Connection Successful So now, this means that the openSSL verification check does not stop with the first matching issuer certificate alone right? Because if that was the case, Scenario 6 should have failed. I have attached my certificates for reference. All are v3 certificates. I am using openssl version "openssl-0.9.8g". One more clarification: >>If OpenSSL client has cert-and-pkey configured and receives CertReq, it sends that cert regardless of any CAlist the server asked for; that cert may be accepted or not depending on the server. And if callback or engine is used it appears (but I haven't tested) that can similarly select any cert regardless of what the server asked. >> Are you indicating here that the client can have multiple end entity certificates? Till now I had the assumption that the server/client can have only a single end entity certificate. Also, if the server can ask client to send selective certificates, wouldn't it be applicable that the client also can request the server for specific certificates? Are there separate openSSL APIs for this or we have to use the same family of ssl_ctx_set_client* family of APIs for this purpose also? Regds, Ashok On Sat, Dec 24, 2011 at 3:19 AM, Dave Thompson wrote: > > From: owner-openssl-us...@openssl.org On Behalf Of Ashok C > > Sent: Thursday, 22 December, 2011 10:55 > > > Another doubt I have is about the SSL_CTX_set_client_ca_list > > and the SSL_get_client_ca_list. > > > I understand that the set method is called by the server to > > set the list of CA names that it actually expects from the client. > > And the client calls ssl_get_client_ca_list to get these names and > > send the appropriate CA certificates in its chain for verification > > to the server. > > Nit: case is important in C identifiers. Skipping that: > > Not quite. Server can call _set_client_CA_list to set the CA names it > *asks for* from the client; server still uses _load_verify_locations > to verify the cert received if any. OpenSSL allows you to make these > different: e.g. ask the client for CA1 and CA2, but verify only CA2, > or CA2 and CA3, or only CA3. I've never seen a good use for this. > > OpenSSL client calls the client_cert callback or engine only if > you did *not* set a cert-and-private-key before the handshake. > Callback or engine can look at the CAlist specified by the server > if any (see next) to choose what cert-and-private-key to use. > For callback it apparently needs to call SSL_get_client_CA_list, > for engine this value is passed separately. > > > I assume that both these methods are actually optional even when > SSL_VERIFY_PEER > > flag is set to true, i.e., client verifies server and server > verifies client. > > If OpenSSL serve
Re: Question on OpenSSL encryption
Hi, In addition to the online material, are there any good books which we can refer to understand openSSL better? Both conceptually as well as from the API/code perspective. We hear of the "Network Security with OpenSSL by John Viega" as one good reference. But it was published in 2002. Any good new books which can be used? Regds, Ashok On Sat, Jan 7, 2012 at 11:44 PM, Ben Laurie wrote: > On Sat, Jan 7, 2012 at 4:12 PM, Manish Jain > wrote: > > > > Hello Michael/Anyone Else, > > > > Can you be kind enough to please point me to some place/URL where I can > get > > a bit more information about how the key is negotiated upon ? > > > > I have gone through a a couple of write-ups on OpenSSL which throw light > > upon everything else except for this vital piece of information. > > http://en.wikipedia.org/wiki/Transport_Layer_Security > > > > > > > Thanks & Regards > > Manish Jain > > > > > > > > On 07-Jan-12 19:23, Michael S. Zick wrote: > >> > >> On Sat January 7 2012, Manish Jain wrote: > >>> > >>> > >>> Hi, > >>> > >>> I am new to OpenSSL and am trying to prepare some illustrative > >>> documentation on how it works. > >>> > >>> AFAIK, OpenSSL uses the concept of a pair of keys per host : one is a > >>> private key which is never communicated to any other host, and the > other > >>> is a public key which is transmitted to the peer (the other party). The > >>> client uses the public key of the server (contained in the server's > >>> certificate) to encrypt its communication, which can only be decrypted > >>> with the server's private key. Please correct me if I am wrong. > >>> > >> > >> That is the essence of what happens and by that the client knows > >> that it is communicating with the server it intended to reach > >> (authentication). > >> > >>> Now the question is : when the server sends data to the client, what > key > >>> does it use for encryption ? > >>> > >> > >> The general answer is: The client and server establish a shared key > >> for that propose early in the protocol. > >> > >>> Does the client communicate its public key > >>> to the server (at some initial stage) which the server uses for > >>> encryption ? > >>> > >> > >> If the communications set up between the two requires client > >> authentication. > >> In many cases the client remains a stranger to the server > >> (un-authenticated). > >> > >>> If yes, what if the client does not have a pair of > >>> public/private keys ? > >>> > >> > >> The usual case for public web browsing using https and some other > >> protocols. > >> The client remains a stranger to the server. > >> > >>> The question arises because it does not seem logical that the server > >>> would its private key for encrypting data to be sent to the client. > >>> Else, snoopers who might have picked the public key could decrypt the > >>> data too. > >>> > >> > >> There is an early stage in nearly all protocols, called: key agreement > >> where the client and server agree on a key without exchanging any of > >> the 'private' information that it is based on. > >> > >>> Any help on clearing up the above points would be greatly appreciated. > >>> > >> > >> My comments above are at a very general level. > >> If the process was as simple as my answers, OpenSSL would not be as > >> large a body of code as it is. ;-) > >> > >> Mike > >>> > >>> > >>> Thank you& > >>> Regards > >>> > >>> Manish Jain > >>> invalid.poin...@gmail.com > >>> > >>> __ > >>> 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: Question on OpenSSL encryption
Thanks Richard, What I am looking would be any good book which gives details about SSL communication like use of certificates, verification of certificates, APIs to examine certificates, certificate revocation concepts/SSL APIs for that, etc. Regds, Ashok 2012/1/9 Richard Könning > Am 09.01.2012 13:10, schrieb Ashok C: > > Hi, >> >> In addition to the online material, are there any good books which we >> can refer to understand openSSL better? Both conceptually as well as >> from the API/code perspective. >> We hear of the "Network Security with OpenSSL by John Viega" as one good >> reference. But it was published in 2002. Any good new books which can be >> used? >> > > Well, the questions of the original poster weren't OpenSSL specific, but > targeted SSL/TLS in general, for this Eric Rescorla's book "SSL and TLS: > Building and Designing Secure Systems" is the better book. Sadly being from > the year 2000 it is somewhat outdated too, but nevertheless a good > introduction to SSL/TLS. For a description of the OpenSSL API afaik the > book from Viega et al. is still the most detailed book, despite being > somewhat outdated. > > For newer versions of TLS (i.e. 1.1 and beyond) one should check newer TLS > books, e.g. the ones from Joshua Davies or Rolf Oppliger. Until now i had > none of the two books in my hands so i can't you tell more about the books, > but maybe a visit at Amazon or similar book traders will give you at least > a detailed content description. > > Ciao, > Richard > > __**__**__ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Optional validation of time in OpenSSL Reg.
Hi, I see that the openSSL certificate verify utility uses the X509_verify_cert() in x509_vfy.c for certificate validation. Based on the manual pages for verify, I understand that the order for verification is as follows: 1. Firstly a certificate chain is built up starting from the supplied certificate and ending in the root CA. 2. The second operation is to check every untrusted certificate's extensions for consistency with the supplied purpose. 3. The third operation is to check the trust settings on the root CA. 4. The final operation is to check the validity of the certificate chain. The validity period is checked against the current system time and the notBefore and notAfter dates in the certificate. The certificate signatures are also checked at this point. What would be the best way to make the time check optional? One way as seen from the code could be to make this call optional based on some environmental variable. Eg: if(TIME_CHECK_ON) check_cert_time(ctx, xs); else don't check time; Is there any alternative way to achieve this? I understand that by passing a custom time using void X509_STORE_CTX_set_time(X509_STORE_CTX *ctx, unsigned long flags, time_t t); and by setting this flag -->X509_V_FLAG_USE_CHECK_TIME, I can make the verify code use the time I provide, but whatever time I provide through the time_t variable, will it be used as notBefore or notAfter time? (since time_t t represents the number of seconds since the start of the Unix epoch). I would need this optional time checking since I cannot count on my system time to be stable all the time :) Regds, Ashok
Support for certificates other than the X509 standard Reg.
Hi, I understand that X509 is the preferred ITU-T standard for PKI. But what would be the other certificate standards which are available and those which a PKI solution needs to support? First question would be whether there are any certificates which do not belong to the X509 standard? Also, what all standards of certificates does the openSSL implementation support? Regds, Ashok
Distinguishing a CA certificate from an end entity certificate Reg.
Hi, What would be the most efficient and easiest way to distinguish a CA certificate from an actual server/client(end entity) certificate? We were thinking of identifying the CA with the "CA:TRUE" constraint from the text display, but again this check does not cover x509 v1 certificates where this extension is not present. Is there any command/openSSL API available which would serve this purpose? Regds, Ashok
Re: Distinguishing a CA certificate from an end entity certificate Reg.
Thanks Jakob, We too have the use cases of those four certificates. Now what would be the best programmatic way to find out for sure if a given certificate is a CA certificate or not, be it a v3 or a v1. Regds, Ashok On Feb 24, 2012 12:51 AM, "Jakob Bohm" wrote: > On 2/23/2012 10:49 AM, Ashok C wrote: > >> Hi, >> >> What would be the most efficient and easiest way to distinguish a CA >> certificate from an actual server/client(end entity) certificate? >> We were thinking of identifying the CA with the "CA:TRUE" constraint from >> the text display, but again this check does not cover x509 v1 certificates >> where this extension is not present. >> Is there any command/openSSL API available which would serve this purpose? >> >> > Ah, a classic FAQ. I think I answered a very similar question > last year, but here we go again. > > In practice you need to distinguish 4 kinds of certificate: > > 1. CA Root. Recognized by being signed by itself (Subject > Distinguished Name exactly same as Issuer Distinguished Name), > by having the CA property not set to FALSE (in other words, it > is TRUE or absent), by having the similar flags and bits in > the other usage properties also allowing use as a CA and by > usually having one of the words "ROOT" or "CA" as a word > substring of its common name (CN in the Subject). (A word > substring is a substring bordered on both sides by end/start > of string or by a non-letter). > > 2. Intermediary CA. Recognized by NOT being signed by itself, > but still having the various usage properties allowing or not > preventing use as a CA. > > 3. Self-Signed End Entity. Recognized by being signed by > itself, but failing one or more of the other checks for being > a CA root, and/or by having a subject name which is directly > usable for an end entity (e.g. a domain name or e-mail > address). These tend to be created quite sloppily, so the > only sure test is if someone uses it as an end entity > certificate. The next best test is that anything not on > YOUR list of trusted CA roots is not a CA root until overridden > by human intervention based on hard offline evidence. > > 4. Regular End Entity. Recognized by NOT being signed by > itself AND being explicitly marked with one or more attributes > preventing use as a CA (most professional CA's don't allow end > entity certificates to act as intermediary CAs, as it would > completely nullify their identity checking efforts and thus > the trustworthiness of their root CA cert). > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2730 Herlev, 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 > > __**__**__ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Is CRL verification automatic in openSSL?
Hi, I am implementing CRL feature for my application and was doing a proof of concept using openSSL. Here is what I did: 1. I used openssl commands to generate a v3 root CA certificate and also the corresponding server certificate. 2. Now i revoked the server certificate using openssl commands. 3. First I tested this with the openSSL s_client and s_server. I understood from googling, that I need to use the -crl-check option in the s_client side to do the CRL validation and as instructed in the reference manual, I concatenated my CA certificate as well as the CRL into a single PEM file and passed it to openssl client in the -CAFile field. 4. Things went as expected and I got the error code for CRL validation failure. 5. Next step, I wanted to do the same for my sample SSL client and server. 6. Here, from my client side, I loaded the concatenated cert + crl into combined.pem and loaded it using 7. SSL_CTX_load_verify_locations(ctx,combined.pem,NULL). While doing the SSL connection, I found that the CRL _was not_ checked. (I understand now that this is NOT the API to set the CRL into verification paths) 8. Later, from further reading I understood that CRL check is not done by default and I need to add the CRL to the verification paths using X509 level APIs. ( http://stackoverflow.com/questions/4389954/does-openssl-automatically-handle-crls-certificate-revocation-lists-now ) >> X509_STORE *store = getStore(); // Enable CRL checking X509_VERIFY_PARAM *param = X509_VERIFY_PARAM_new(); X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_CRL_CHECK); X509_STORE_set1_param(store, param); X509_VERIFY_PARAM_free(param); >> I am going to try this out now, but before that , wanted to check with the community: - If the way I am proceeding is correct? - Are there any other simpler ways to do this? - What would be best approach to follow for CRL checking enabling? - Are there any SSL_CTX level APIs for this now? I am using openssl version openssl-0.9.8r(Also wanted to know if this behaviour has changed in higher versions of openssl) Thanks in advance! Regds, Ashok
Re: Is CRL verification automatic in openSSL?
Hi, On further investigation, we have found that the addition of the following piece of code enables the CRL checking. X509_STORE *store = getStore(); // Enable CRL checking X509_VERIFY_PARAM *param = X509_VERIFY_PARAM_new(); X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_CRL_CHECK); X509_STORE_set1_param(store, param); X509_VERIFY_PARAM_free(param); And it is also clear that we need to use SSL_CTX_load_verify_locations() is required to be used to load CA certificate + CRL concatenated into a PEM file.(Alternatively CAPath also, but we did not try that yet). I guess my problems are solved for now. If you guys have any comments on this, please let me know. Otherwise you can ignore the previous email. Regds, Ashok On Wed, Mar 28, 2012 at 10:08 PM, Ashok C wrote: > Hi, > > I am implementing CRL feature for my application and was doing a proof of > concept using openSSL. > Here is what I did: > >1. I used openssl commands to generate a v3 root CA certificate and >also the corresponding server certificate. >2. Now i revoked the server certificate using openssl commands. >3. First I tested this with the openSSL s_client and s_server. I >understood from googling, that I need to use the -crl-check option in the >s_client side to do the CRL validation and as instructed in the reference >manual, I concatenated my CA certificate as well as the CRL into a single >PEM file and passed it to openssl client in the -CAFile field. >4. Things went as expected and I got the error code for CRL validation >failure. >5. Next step, I wanted to do the same for my sample SSL client and >server. >6. Here, from my client side, I loaded the concatenated cert + crl >into combined.pem and loaded it using >7. SSL_CTX_load_verify_locations(ctx,combined.pem,NULL). While doing >the SSL connection, I found that the CRL _was not_ checked. (I understand >now that this is NOT the API to set the CRL into verification paths) >8. Later, from further reading I understood that CRL check is not done >by default and I need to add the CRL to the verification paths using X509 >level APIs. ( > > http://stackoverflow.com/questions/4389954/does-openssl-automatically-handle-crls-certificate-revocation-lists-now >) > > >> > > X509_STORE *store = getStore(); > > > > // Enable CRL checking > > X509_VERIFY_PARAM *param = X509_VERIFY_PARAM_new(); > > X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_CRL_CHECK); > > X509_STORE_set1_param(store, param); > > X509_VERIFY_PARAM_free(param); > >> > > I am going to try this out now, but before that , wanted to check with the > community: > >- If the way I am proceeding is correct? >- Are there any other simpler ways to do this? >- What would be best approach to follow for CRL checking enabling? >- Are there any SSL_CTX level APIs for this now? > > > I am using openssl version openssl-0.9.8r(Also wanted to know if this > behaviour has changed in higher versions of openssl) > Thanks in advance! > > Regds, > Ashok > > >
Re: expired ssl certificate
Hi,
I had almost the same requirement and eventually achieved it by patching my
openssl package's x509_verify code to do the check_cert_time() method
optionally depending on some conditions. Ideally I feel openSSL should
provide a validation flag like
*X509_V_FLAG_IGNORE_LIFETIME **which would help in this case. I can see
many existing flags listed here.** *
http://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_flags.html#VERIFICATION_FLAGS
Is there any specific reason as to why OpenSSL does not want to support
this feature?
Regds,
Ashok
On Thu, Apr 12, 2012 at 12:26 AM, Erwin Himawan wrote:
> Reading Nou's proposal, I have the impression that the client needs to be
> modified to accept expired server's certificate. Is my understanding
> correct? If my understanding is corrrect, the client needs to be updated.
>
> If the client needs to be updated, In my opinion, it is simpler to update
> the client with a new server certificate.
> However, you should not use a selfsigned certificate for your serve
> certificate. Instead, I am proposing to create a chain of certificate
> (PKI). You could avoid this problem in the future by creating a simple
> PKI. FUrther you could expand this PKI to issue certificate for other
> application.
>
> This is what I am proposing:
> 1. Create a long lived self-signed CA certificate (for example: 20 or 30
> years); This self-signed certificate is called trust anchor certificate.
> Make sure, basic constraint CA is set to true.
> Do not make the expiration less than 5 years, since you will have the
> same issue again in the next 5 year to roll-over your trust anchor
> certificate. Also, keep the private key of this CA as safe as possible.
> THis is your root of trust. If you compromise this root CA private key,
> your PKI becomes void.
> 2. Distribute this self-signed certificate to all clients and install this
> as the trusted certificate.
> 3. Have this self-signed CA (trust anchor) created in step-1 issues the
> server certificate. For this server certificate, validity period does not
> matter. Of course you do not want to make the validity period too short
> since you have to frequently update the server certificate when it is
> expired.
>
> Using this proposed method, you can update or change the server
> certificate as often as you like.
> The server certificate is typically included in the SSL's ServerHello
> message, so the client always got the server certificate during SSL
> handshake. I think (?) the server could also include the chain of
> certificate up to the trust anchor certificate.
>
> When the client receives the server certificate issued by the self-signed
> CA (the self-signed CA certificate could also be included in the
> ServerHello), the client can verify this certificate chain up to the
> self-signed CA certificate. If the chain can be verified, then the server
> certificate is successfully validated. Hence, the server can be
> cryptographically authenticated.
>
> Using Nou's proposal, your client would practically accept any self-signed
> certificate and prone to man-in-the-middle attack. The client can
> cryptographically verify the server certificate, but the client can not
> cryptographically authenticate the server since the client does not have
> the knowledge of the server's legitimate public key. Using my proposal,
> your client can cryptographically authenticate the server, by verifying the
> digital signature in the server's certificate using the (selfsigned) CA
> certificate. The selfsigned CA certificate is then verified against a list
> of trusted certificates. My proposal is actually similar with what you are
> doing currently. The difference between my proposal and yours is: in yours,
> you verify the server certificate against a list of trusted certificates.
> In my proposal, you verify the server certificate using the CA certificate
> which is in a list of trusted certificates.
>
> Erwin
>
>
> On Wed, Apr 11, 2012 at 11:34 AM, Nou Dadoun wrote:
>
>> 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
MAC address binding to the certificate
Hi all I am using certificates generated by openssl for authenticating the WiFi useres using EAP-TLS 802.1x authentication. I would like to add MAC address of the user machines into each user certificates so that the certificates used by one machine cannot be used in another machine/PC. Could anyone please help how to create certificate with MAC address binded to it. Regards Anoop Get your world in your inbox! Mail, widgets, documents, spreadsheets, organizer and much more with your Sifymail WIYI id! Log on to http://www.sify.com ** DISCLAIMER ** Information contained and transmitted by this E-MAIL is proprietary to Sify Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at ad...@sifycorp.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: MAC address binding to the certificate
Hi Patrik Thanks for the quick response. I totally agree on your point. Our associates often used to try others certificate .So I want to remove that threat also by incorporating MAC address also into the certificates apart from the existing set up. Often Wimax CPE vendors used to bind the MAC along with the certificate so that ones certificate cannot be installed to another CPE. I want to remove the risk of certificate stealing. Of course I am usin CRL for revoking. Still want to know any possibility of adding MAC also to certificate Regards Anoop C Access Network Engineering Sify Technologies Ltd. Chennai Mobile: +91 - 9884015161 Xtn:2867 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Patrick Patterson Sent: Wednesday, September 09, 2009 5:50 PM To: openssl-users@openssl.org Subject: Re: MAC address binding to the certificate Hi there: Anoop C wrote: > Hi all > > I am using certificates generated by openssl for authenticating the > WiFi useres using EAP-TLS 802.1x authentication. > I would like to add MAC address of the user machines into each user > certificates so that the certificates used by one machine cannot be used in > another machine/PC. > > Could anyone please help how to create certificate with MAC address > binded to it. > I think that you may want to revisit your assumptions here - it is rather trivial to spoof a MAC address, so basing your security on that is not very good. Besides, as long as the user has a valid certificate, why do you care which machine they log in from? If you can't trust the holder of the certificate to keep it safe, then you have a different set of issues that MAC address binding will not save you from. Have fun. Patrick. > Regards > Anoop > > > > Get your world in your inbox! > > Mail, widgets, documents, spreadsheets, organizer and much more with your Sifymail WIYI id! > Log on to http://www.sify.com > > ** DISCLAIMER ** > Information contained and transmitted by this E-MAIL is proprietary to > Sify Limited and is intended for use only by the individual or entity to > which it is addressed, and may contain information that is privileged, > confidential or exempt from disclosure under applicable law. If this is a > forwarded message, the content of this E-MAIL may not have been sent with > the authority of the Company. If you are not the intended recipient, an > agent of the intended recipient or a person responsible for delivering the > information to the named recipient, you are notified that any use, > distribution, transmission, printing, copying or dissemination of this > information in any way or in any manner is strictly prohibited. If you have > received this communication in error, please delete this mail & notify us > immediately at ad...@sifycorp.com > __ > 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 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.83/2353 - Release Date: 09/08/09 20:45:00 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
C++ Invoke delegate
Hello,
I'd really appreciate if someone can give me an example of how to do this,
I've been spending some time on this without any luck, I'm new to c++ so for
you guys it should be pretty easy.
I'm trying to get the SSL state info and trying to invoke a delegate to pass
the information but I'm not getting any where, here is what I have:
1) I've created a delegate with the following method:
public __delegate void SSLStateInfo
2) Then inside the following block:
__sealed public __gc class SSLClient : public IDisposable
{
I have added:
SSLStateInfo* DoSSLStateInfo;
3) Upon initialization I call the following:
SSL_CTX_set_info_callback(ctx,apps_ssl_info_callback);
4) At this point I can get the state info in the apps_ssl_info_callback
function but what I would like to do is call the DoSSLStateInfo delegate and
pass it the state info (in the form of a string).
What do I need to do inside the apps_ssl_info_callback function to invoke
the delegate?
I've searched through lots of sites but I can't seem to find a simple
example.
I'd really appreciate the help.
Thanks,
Joseph
--
View this message in context:
http://www.nabble.com/C%2B%2B-Invoke-delegate-tp25636867p25636867.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
how to merge multiple public domain certs into one file?
Hi... I've been struggling with how to concatenate multiple public domain certs into one crt file. Basically, I have 5 SSL virtual host domains running on 1 apache httpd server and each host has a separate GeoTrust domain certificate. Instead of having 5 individual public *.crt files, is there anyway to merge them together into 1 file. Any information would be much appreciated. Thanks in advance, Michael
Unable to create root certificate in FC7
Hi I am getting the following error while generating root certificate. I am using FC7 with the following openssl packages openssl-0.9.6g.tar.gz openssl-0.9.7-beta3.tar.gz openssl-SNAP-20021027.tar.gz The same was working with RHEL3 and Redhat 4 openssl: error while loading shared libraries: /usr/local/openssl-certgen/lib/libcrypto.so.0.9.7: cannot restore segment prot after reloc: Permission denied Kindly advice how can I over come the issue Regards Anoop C Get your world in your inbox! Mail, widgets, documents, spreadsheets, organizer and much more with your Sifymail WIYI id! Log on to http://www.sify.com ** DISCLAIMER ** Information contained and transmitted by this E-MAIL is proprietary to Sify Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at ad...@sifycorp.com
RE: Unable to create root certificate in FC7
Could anyone tell the procedure to set up the Openssl in fc7..I am using the certificates for EAP-TLS authentication. What are the packages I need to install? Currently I am using three scripts to generate certificates. I am attaching it. Thanks in advance. Regards Anoop C From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Anoop C Sent: Wednesday, November 18, 2009 7:38 PM To: openssl-users@openssl.org Subject: Unable to create root certificate in FC7 Hi I am getting the following error while generating root certificate. I am using FC7 with the following openssl packages openssl-0.9.6g.tar.gz openssl-0.9.7-beta3.tar.gz openssl-SNAP-20021027.tar.gz The same was working with RHEL3 and Redhat 4 openssl: error while loading shared libraries: /usr/local/openssl-certgen/lib/libcrypto.so.0.9.7: cannot restore segment prot after reloc: Permission denied Kindly advice how can I over come the issue Regards Anoop C No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.425 / Virus Database: 270.14.72/2511 - Release Date: 11/18/09 07:50:00 CA.clt Description: Binary data CA.root Description: Binary data CA.svr Description: Binary data
Openssl issue??
I am trying to to use ftps for secure server. We have two identical client trying to connect to the server.Client 1 can connect but not client 2. Client 2 throws below error error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag Openssl on both clients openssl-0.9.7a-43.1 xmlsec1-openssl-1.2.6-3 openssl-devel-0.9.7a-43.1 client 1 --- curl -3 -v --ftp-ssl -k -S ftp://abc:xyz...@10.10.10.1 * About to connect() to 10.10.10.1 port 21 * Trying 10.10.10.1... * connected * Connected to 10.10.10.1 (10.10.10.1) port 21 < 220 (vsFTPd 2.0.1) > AUTH SSL < 234 Proceed with negotiation. * successfully set certificate verify locations: * CAfile: /usr/share/ssl/certs/ca-bundle.crt CApath: none * SSL connection using DES-CBC3-SHA * Server certificate: *subject: /C=US/ST=NJ/L=FP/O=test/CN=test.test.com *start date: 2010-03-31 04:53:33 GMT *expire date: 2011-03-31 04:53:33 GMT *common name: test.test.com (does not match '10.10.10.1') *issuer: /C=US/ST=NJ/L=FP/O=test/CN=test.test.com * SSL certificate verify result: error number 1 (18), continuing anyway. > USER abc < 331 Please specify the password. > PASS xyz123 < 530 Login incorrect. * the username and/or the password are incorrect * Closing connection #0 client2 # curl -3 -v --ftp-ssl -k -S ftp://abc:xyz...@10.10.10.1 * About to connect() to 10.10.10.1 port 21 * Trying 10.10.10.1... * connected * Connected to 10.10.10.1 (10.10.10.1) port 21 < 220 (vsFTPd 2.0.1) > AUTH SSL < 234 Proceed with negotiation. * successfully set certificate verify locations: * CAfile: /usr/share/ssl/certs/ca-bundle.crt CApath: none * error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag * Closing connection #0 Cheers CG __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
API to extract Subject/Issuer Name from X509 certificate
Hi, I was trying to find the correct API for extracting the subject/issuer name from an x509 certificate using openssl library, but was unable to find the exact one. It would be great if someone guides me regarding this. Thanks in Advance! Regds, Ashok
Optional Verification of Signature and Date..
Hi, Does the openssl X509_verify certificate validation API support an argument that supports skipping of signature and date validation? Or is there any other way that I can achieve this optional verification. Please help me out in this regard. Regds, Ashok.
Optional Verification of Signature and Date..
Hi, I am a newbie user of openssl, and am using openssl C apis to verify certificates. Is there any way by which I can ignore the date verificationa and the signature verification? Thanks in advance. Regds, Ashok
RE: Certificates on embedded systems without filesystems
I see these in ssl.h int SSL_CTX_use_certificate(SSL_CTX *ctx, X509 *x); int SSL_CTX_use_certificate_ASN1(SSL_CTX *ctx, int len, unsigned char *d); and I've used the SSL_CTX_use_certificate_ASN1(), with 'd' being a DER encoded cert in a buffer Bhagvan David Schwartz <[EMAIL PROTECTED]> wrote: > i mean is there any equivalent function for > SSL_CTX_use_certificate_chain_file which takes certificate buffer > instead of certificate file name. Just look at the source code to SSL_CTX_use_certificate_chain_file. As I recall (it has been awhile) you will find code in there that address the certificates from the file one-by-one. Just follow the same pattern getting the certificates from wherever. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
clear text vs opaque signature
Hello everybody, I would like to ask what is the difference, from the cryptographic point of view, between an opaque signature (-nodetach) and a clear text signature. Thanks in advance for your answers, Jan. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: clear text vs opaque signature
Hi, ok, so the clear text signature general form is something like: --A3DB62BE42E8E4D7716813FA55957190 My Signed Text --A3DB62BE42E8E4D7716813FA55957190 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIFlgYJKoZIhvcNAQcCoIIFhzCCBYMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 ... --A3DB62BE42E8E4D7716813FA55957190-- And the opaque is the same thing but entirely encoded en B64 and attached to the email as attachment ? Is that correct ? Regards, Jan On Wed, Feb 11, 2009 at 4:42 PM, Dr. Stephen Henson wrote: > On Wed, Feb 11, 2009, Jan C. wrote: > >> Hello everybody, >> I would like to ask what is the difference, from the cryptographic >> point of view, between an opaque signature (-nodetach) and a clear >> text signature. >> > > No cryptographic difference at all: they are different ways of packaging the > same thing. > > In practical terms the cleartext multipart/mime version can sometimes be > corrupted by mail gateways whereas the embedded signature form is more > resistant. > > The embedded form in MIME messages is often base64 encoded which will increase > its size. > > Current versions of OpenSSL can only verify embedded signatures if the whole > content is in memory. Version 0.9.9 can generate embedded signatures on the > fly though. > > Steve. > -- > Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage > OpenSSL project core developer and freelance consultant. > Homepage: http://www.drh-consultancy.demon.co.uk > __ > 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: clear text vs opaque signature
On Thu, Feb 12, 2009 at 12:46 PM, Dr. Stephen Henson wrote: > On Thu, Feb 12, 2009, Jan C. wrote: > >> Hi, >> ok, so the clear text signature general form is something like: >> >> >> --A3DB62BE42E8E4D7716813FA55957190 >> >> My Signed Text >> >> --A3DB62BE42E8E4D7716813FA55957190 >> Content-Type: application/x-pkcs7-signature; name="smime.p7s" >> Content-Transfer-Encoding: base64 >> Content-Disposition: attachment; filename="smime.p7s" >> >> MIIFlgYJKoZIhvcNAQcCoIIFhzCCBYMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 >> ... >> >> --A3DB62BE42E8E4D7716813FA55957190-- >> >> >> >> And the opaque is the same thing but entirely encoded en B64 and >> attached to the email as attachment ? Is that correct ? >> > > Cleartext would have MIME headers in the first part. > > Opaque includes the content in the signature structure so you only get one > part. Ok > > If you want to see what they look like generate a few with the smime utility. That's what I did but I wanted to understand the generated format ;) Thanks, Jan > > Steve. > -- > Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage > OpenSSL project core developer and freelance consultant. > Homepage: http://www.drh-consultancy.demon.co.uk > __ > 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
Reading DER format public Key Using JSAFE ToolKit
Hello Experts, i am implementing Digital Signature process in our application using the CRYPTO - J toolkit (JSAFE). i need to read the DER encoded ASN.1 or PEM format Public Key. Can you please help me to read this file using the JSAFE tool kit? Thanks Dinesh
Unique naming convention that can be used for certificates Reg.
Hi, What would be the unique names with which I can store CA certificates in file system? I understand that issuer-id and serial number are the unique identifiers for a certificate. But using this name for a certificate file name makes it very long and also introduces some characters like "@,=" etc, which I consider undesirable for file naming. I considered using serial number, but one more thing I want to achieve is that by looking at the file name I should be able to identify what certificate it actually is. Eg: verisign-subca3.pem would mean that this is the 3rd subordinate CA from verisign. These certificates are copied to the filesystem by my application and I need to generate these names from the certificates and also make sure that each name is unique and does not clash in any way and also in compliance with the UNIX file naming standards. Regds, Ashok
Re: Forming the correct chain for an end entity certificate Reg.
Thanks Sukalp, But I would like confirmation for the algorithm also. Whether SKI/AKI related checks are sufficient for the chain formation, or if anything else needs to be checked. -- Ashok On Mon, Jul 23, 2012 at 12:54 PM, Sukalp Bhople wrote: > Hi, > > You can have a look at following files from openssl source code. > > 1. ssl_cert.c (around line number 626) > 2. x509_vfy.c (around line number 153) > 3. v3_purp.c (around line number 700). > > good luck! > > On Mon, Jul 23, 2012 at 8:41 AM, Ashok C wrote: > >> Hi, >> >> I have a requirement to form a correct certificate chain (for a server >> application, to send to client). >> Currently I was forming the chain using the issuer-id and subject name >> combination alone. >> Eg: The algorithm followed was: >> Let End entity(server certificate) be called as 'E'. Root certificate as >> 'R' , and intermediate CA certificate be 'I'. >> >> >>1. Look up E's issuer-id. Let it be 'C=IN'. Chain at this step: "E" >>2. Search trust store for CA certificate which has this 'C=IN' as >>subject name and add it to chain. This is "I". Chain at this step: "E-I" >>3. Look at issuer-id of I and search trust store which has it as >>subject-name. In this case I will find 'R'. Since for 'R' issuer-id and >>subject-name are same, this is considered to be root and hence not added >> to >>chain. >> >> But, I find that this chain is not conclusive enough, as >> subject-name==issuer-id is not a complete criteria for a root certificate >> and also that "I" cannot be treated as issuer of "E" just because of the >> success of the issuer-id/subject-name checks. >> I read the openSSL verify man page and understood that checks related to >> authority key identifier and subject key identifier are required to decide >> upon the correct chain. >> >> So I presume that the logic should be modified to look something like >> this: >> >> >>1. Look up E's issuer-id. Let it be 'C=IN'. Chain at this step: "E" >>2. Search trust store for CA certificate which has this 'C=IN' as >>subject name. This is "I". Check if authority key identifier of "E" is the >>same as the subject key identifier of "I". If this is true, add it to >>chain. Chain at this step: "E-I" >>3. Look at issuer-id of I and search trust store which has it as >>subject-name. In this case I will find 'R'. Check if authority key >>identifier of "I" is the same as the subject key identifier of "R". 'R' >> can >>be concluded as the root only if subject-name==issuer-id and >>authority-key-identifier==subject-key-identifier. >> >> Is this solution complete for a multi-level hierarchy? As of now, I do >> not have to deal with cross-certification, though I am very interested to >> know from you guys on the complications involved when that comes into the >> picture. I understand there is RFC 4158 explaining this path formation, but >> was wondering that needs to be read in detail only for the >> cross-certification related parts. >> >> Does openSSL have any sample implementation somewhere for this path >> formation(subject-key/authority-key checks) which I could use for reference? >> Thanks in advance. >> >> Regards, >> Ashok >> >> > > > -- > Regards, > *Sukalp Bhople.* > >
Re: Forming the correct chain for an end entity certificate Reg.
Hi, I read from the RFC5280 that AKI is mandatory for all certificates generated by a conforming CA. "The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. The signature on a self-signed certificate is generated with the private key associated with the certificate's subject public key. (This proves that the issuer possesses both the public and private keys.) In this case, the subject and authority key identifiers would be identical, but only the subject key identifier is needed for certification path building." And that Subject Key Identifier is "MUST" for CA certificates but only "SHOULD" for end entity certificates. "For end entity certificates, the subject key identifier extension provides a means for identifying certificates containing the particular public key used in an application. Where an end entity has obtained multiple certificates, especially from multiple CAs, the subject key identifier provides a means to quickly identify the set of certificates containing a particular public key. To assist applications in identifying the appropriate end entity certificate, this extension SHOULD be included in all end entity certificates". I am going to support only v3 certificates in which the above extensions seem to be MUST(For EE I don't need the SKI to be processed anyways, AKI is sufficient). So the go ahead I would need from the community is whether the AKI/SKI checks are sufficient for chain formation in a v3 PKI or not. -- Ashok On Mon, Jul 23, 2012 at 1:48 PM, Sukalp Bhople wrote: > Hi Ashok, > > If you have a look at the v3_purp.c, > > You can follow following algorithm: > 1. check issuer name, if okay then proceed or exit. > 2. check akid, > 3. check the key usage ... (if the issuer certificate in the chain for a > subject under consideration is allowed to sign or not), > 4. check the path length constraint., and check for proxy certificates. > > As far as understood from openssl source code, it checks the akid only if > it is present in the certificate otherwise it only depends on the subject > name and issuer name match. > > Of course, at the end you need to verify the signature. But thats not the > part of the certificate chain formation. > > > On Mon, Jul 23, 2012 at 10:06 AM, Ashok C wrote: > >> Thanks Sukalp, >> >> But I would like confirmation for the algorithm also. >> Whether SKI/AKI related checks are sufficient for the chain formation, or >> if anything else needs to be checked. >> >> -- >> Ashok >> >> >> On Mon, Jul 23, 2012 at 12:54 PM, Sukalp Bhople wrote: >> >>> Hi, >>> >>> You can have a look at following files from openssl source code. >>> >>> 1. ssl_cert.c (around line number 626) >>> 2. x509_vfy.c (around line number 153) >>> 3. v3_purp.c (around line number 700). >>> >>> good luck! >>> >>> On Mon, Jul 23, 2012 at 8:41 AM, Ashok C wrote: >>> >>>> Hi, >>>> >>>> I have a requirement to form a correct certificate chain (for a server >>>> application, to send to client). >>>> Currently I was forming the chain using the issuer-id and subject name >>>> combination alone. >>>> Eg: The algorithm followed was: >>>> Let End entity(server certificate) be called as 'E'. Root certificate >>>> as 'R' , and intermediate CA certificate be 'I'. >>>> >>>> >>>>1. Look up E's issuer-id. Let it be 'C=IN'. Chain at this step: "E" >>>>2. Search trust store for CA certificate which has this 'C=IN' as >>>>subject name and add it to chain. This is "I". Chain at this step: "E-I" >>>>3. Look at issuer-id of I and search trust store which has it as >>>>subject-name. In this case I will find 'R'. Since for 'R' issuer-id and >>>>subject-name are same, this is considered to be root and hence not >>>> added to >>>>chain. >>>> >>>> But, I find that this chain is not conclusive enough, as >>>> subject-name==issuer-id is not a complete criteria for a root certificate >>>> and also that "I" cannot be treated as issuer of "E" just because of the >>>
Re: Forming the correct chain for an end entity certificate Reg.
Hi, Could someone please confirm the points I mentioned in the previous email? Also wanted to understand on how to identify cross certificates using openSSL. I understand that the AKI checks are not sufficient when cross certificates are present in my certificate chain. -- Ashok On Mon, Jul 23, 2012 at 2:09 PM, Ashok C wrote: > Hi, > > I read from the RFC5280 that AKI is mandatory for all certificates > generated by a conforming CA. > "The keyIdentifier field of the authorityKeyIdentifier extension MUST >be included in all certificates generated by conforming CAs to >facilitate certification path construction. There is one exception; >where a CA distributes its public key in the form of a "self-signed" >certificate, the authority key identifier MAY be omitted. The >signature on a self-signed certificate is generated with the private >key associated with the certificate's subject public key. (This >proves that the issuer possesses both the public and private keys.) >In this case, the subject and authority key identifiers would be >identical, but only the subject key identifier is needed for >certification path building." > > And that Subject Key Identifier is "MUST" for CA certificates but only > "SHOULD" for end entity certificates. > > "For end entity certificates, the subject key identifier extension >provides a means for identifying certificates containing the >particular public key used in an application. Where an end entity >has obtained multiple certificates, especially from multiple CAs, the >subject key identifier provides a means to quickly identify the set >of certificates containing a particular public key. To assist >applications in identifying the appropriate end entity certificate, >this extension SHOULD be included in all end entity certificates". > > I am going to support only v3 certificates in which the above extensions > seem to be MUST(For EE I don't need the SKI to be processed anyways, AKI is > sufficient). > So the go ahead I would need from the community is whether the AKI/SKI > checks are sufficient for chain formation in a v3 PKI or not. > > -- > Ashok > > On Mon, Jul 23, 2012 at 1:48 PM, Sukalp Bhople wrote: > >> Hi Ashok, >> >> If you have a look at the v3_purp.c, >> >> You can follow following algorithm: >> 1. check issuer name, if okay then proceed or exit. >> 2. check akid, >> 3. check the key usage ... (if the issuer certificate in the chain for a >> subject under consideration is allowed to sign or not), >> 4. check the path length constraint., and check for proxy certificates. >> >> As far as understood from openssl source code, it checks the akid only if >> it is present in the certificate otherwise it only depends on the subject >> name and issuer name match. >> >> Of course, at the end you need to verify the signature. But thats not the >> part of the certificate chain formation. >> >> >> On Mon, Jul 23, 2012 at 10:06 AM, Ashok C wrote: >> >>> Thanks Sukalp, >>> >>> But I would like confirmation for the algorithm also. >>> Whether SKI/AKI related checks are sufficient for the chain formation, >>> or if anything else needs to be checked. >>> >>> -- >>> Ashok >>> >>> >>> On Mon, Jul 23, 2012 at 12:54 PM, Sukalp Bhople wrote: >>> >>>> Hi, >>>> >>>> You can have a look at following files from openssl source code. >>>> >>>> 1. ssl_cert.c (around line number 626) >>>> 2. x509_vfy.c (around line number 153) >>>> 3. v3_purp.c (around line number 700). >>>> >>>> good luck! >>>> >>>> On Mon, Jul 23, 2012 at 8:41 AM, Ashok C wrote: >>>> >>>>> Hi, >>>>> >>>>> I have a requirement to form a correct certificate chain (for a server >>>>> application, to send to client). >>>>> Currently I was forming the chain using the issuer-id and subject name >>>>> combination alone. >>>>> Eg: The algorithm followed was: >>>>> Let End entity(server certificate) be called as 'E'. Root certificate >>>>> as 'R' , and intermediate CA certificate be 'I'. >>>>> >>>>> >>>>>1. Look up E's issuer-id. Let it be 'C=IN'. Chain at this step: >>>>>"E" >>>>>2. Search trust store for CA certificate which has t
Re: [openssl] Forming the correct chain for an end entity certificate Reg.
Also adding openSSL community into loop. Thanks Dave. But main use case for me is the trust anchor update case. I have a certain requirement which goes like this: I have a client application which runs on my machine and it will attempt to connect to multiple remote servers. *At time T0:* Client has old root. All servers have old end entity, connection goes fine. *At time T1:* Trust anchor updates itself and my client gets hold of the new root. But at the same time it will not delete the old root since some servers would not yet have procured the new end entity from the new root. At this time, both roots would be present in my trust store. And I will need to form the right certificate chain for a display command which should display: new EE-->new root. And not new EE-->old root. For this, I would need the AKI/SKI related checks. Since the issuer-id subject-name fields of both old as well as new root would be same. And regarding the "some even don't have AKI/SKI", I read the RFC and it mandates the presence of these extensions in all conforming CAs. -- Ashok On Fri, Jul 27, 2012 at 4:18 AM, Dave Thompson wrote: > ** > I'm not certain that actually works as described. > > I see the checks in crypto/x509/x509_vfy.c and crypto/x509v3/v3_purp.c, > but the 'search for parent' part has multiple options spread over several > sourcefiles -- > the standard ways are to look in a file commonly designated CAfile and/or > a directory commonly designated CApath, but there are several ways to > extend this. > There are comments on x509_lu.c _get1_issuer, but I'm not sure if/when > they apply. > > It has never been an issue for me, because all the CAs I've seen > have distinct DN's for each cert they issue, i.e. they never need > to disambiguate using AKI/SKI. And some don't even *have* AKI/SKI. > > Good luck. > > -- > *From:* Ashok C [mailto:ash@gmail.com] > *Sent:* Thursday, 26 July, 2012 02:08 > *To:* Dave Thompson > *Subject:* Fwd: Forming the correct chain for an end entity certificate > Reg. > > Hi Dave, > > Could you please help me on this? > > -- > Ashok > > -- Forwarded message -- > From: Ashok C > Date: Mon, Jul 23, 2012 at 12:11 PM > Subject: Forming the correct chain for an end entity certificate Reg. > To: openssl-users@openssl.org > > > Hi, > > I have a requirement to form a correct certificate chain (for a server > application, to send to client). > Currently I was forming the chain using the issuer-id and subject name > combination alone. > Eg: The algorithm followed was: > Let End entity(server certificate) be called as 'E'. Root certificate as > 'R' , and intermediate CA certificate be 'I'. > > >1. Look up E's issuer-id. Let it be 'C=IN'. Chain at this step: "E" >2. Search trust store for CA certificate which has this 'C=IN' as >subject name and add it to chain. This is "I". Chain at this step: "E-I" >3. Look at issuer-id of I and search trust store which has it as >subject-name. In this case I will find 'R'. Since for 'R' issuer-id and >subject-name are same, this is considered to be root and hence not added to >chain. > > But, I find that this chain is not conclusive enough, as > subject-name==issuer-id is not a complete criteria for a root certificate > and also that "I" cannot be treated as issuer of "E" just because of the > success of the issuer-id/subject-name checks. > I read the openSSL verify man page and understood that checks related to > authority key identifier and subject key identifier are required to decide > upon the correct chain. > > So I presume that the logic should be modified to look something like this: > > >1. Look up E's issuer-id. Let it be 'C=IN'. Chain at this step: "E" >2. Search trust store for CA certificate which has this 'C=IN' as >subject name. This is "I". Check if authority key identifier of "E" is the >same as the subject key identifier of "I". If this is true, add it to >chain. Chain at this step: "E-I" >3. Look at issuer-id of I and search trust store which has it as >subject-name. In this case I will find 'R'. Check if authority key >identifier of "I" is the same as the subject key identifier of "R". 'R' can >be concluded as the root only if subject-name==issuer-id and >authority-key-identifier==subject-key-identifier. > > Is this solution complete for a multi-level hierarchy? As of now, I do not > have to deal with cross-certification, though I am very interested to know > from you guys on the complications involved when that comes into the > picture. I understand there is RFC 4158 explaining this path formation, but > was wondering that needs to be read in detail only for the > cross-certification related parts. > > Does openSSL have any sample implementation somewhere for this path > formation(subject-key/authority-key checks) which I could use for reference? > Thanks in advance. > > Regards, > Ashok > > >
Re: [openssl] Forming the correct chain for an end entity certificate Reg.
Thanks Dave. That clarifies part of my question. The next part is regarding cross certificates. For the normal multilevel hierarchy, AKI check seems to be sufficient to identify the correct CA in the chain. But when cross certificates come into the picture, will the AKI checks still hold good? I hear they are not. Would you have some opinion/understanding regarding this? -- Ashok On Mon, Jul 30, 2012 at 8:17 AM, Dave Thompson wrote: > >From: Ashok C [mailto:ash@gmail.com] > >Sent: Saturday, 28 July, 2012 01:21 > > >Thanks Dave. But main use case for me is the trust anchor update case. > >I have a certain requirement which goes like this: > >I have a client application which runs on my machine and it will attempt > >to connect to multiple remote servers. > >At time T0: > >Client has old root. All servers have old end entity, connection goes > fine. > >At time T1: > >Trust anchor updates itself and my client gets hold of the new root. > >But at the same time it will not delete the old root since some servers > >would not yet have procured the new end entity from the new root. > >At this time, both roots would be present in my trust store. And I will > >need to form the right certificate chain ... For this, I would need > >the AKI/SKI related checks. Since the issuer-id subject-name fields > >of both old as well as new root would be same. > > Will they? Most public CAs use different names. *Similar*, like > Verisign blah blah G3 and Verisign blah blah G4, but different. > > If you are using a CA where DN is kept the same, yes you need AKI*, > or else you need to do trial and error. Good luck. (* Technically > this could be AKI->IssuerAndSerial, as long as serial is unique, > instead of AKI->SKI. But I've not seen anyone use that.) > > >And regarding the "some even don't have AKI/SKI", I read the RFC and > >it mandates the presence of these extensions in all conforming CAs. > > Conforming, yes. In the real world, it isn't always true that everybody > conforms. But at least when they're not conforming, you can tell your > users to blame them. That usually helps for about 5 minutes. > > >
How to find correct issuer certificate in multi-level hierarchy?
Hi,
Is there a way in which I can determine the correct issuer certificate of
an issued certificate(either intermediate CA or end entity) based on
comparing immediate pair alone.
Eg:
My hierarchy is like this:
Root
Intermediate CA 1
Intermediate CA 2
End entity
Is it possible to determine that Intermediate CA2 is the issuer of the End
entity certificate without having to traverse the full hierarchy?
I do not want to depend upon issuername-subjectname comparisons alone(As
this is not deterministic and conclusive).
I do not want to depend upon Authority Key Identifier /Subject Key
Identifier's keyId fields(As most CAs seem to not have this extension at
all)
Basically I want some signature check method from openSSL can take two
certificates as input and tell me if one has issued the other:
int openSSL_signature_check(X509* issuer_certificate, X509*
issued_certificate)
{
int return_code = signature_check(issuer_certificate,
issued_certificate)
if (0 == return_code)
return YES_ISSUER_IS_CORRECT;
else
return NO_ISSUER_IS_NOT_CORRECT;
}
Is something like this already available in openSSL?
One more question:
Given a certificate and trust store, openSSL's verify utility currently
returns OK in case the verification was successful. Is there a way in which
I can retrieve the formed and verified chain of certificates back?
--
Ashok
Re: How to find correct issuer certificate in multi-level hierarchy?
Thank you Jacob and Stephen.
That brings one more question which was posted by Klaus sometime back:
"Hi!
I wrote a small program which dumps all root certificates from Windows
certificate store into a file. Then I use openssl to connect to Google and
validate its certificate:
openssl s_client -connect www.google.com:443 -CAfile dump.crt
When using openssl0.9.8k or openssl0.9.8x everything works as expected.
When using openssl1.0.0g or openssl 1.0.1c the certificate validation fails
with:
Verify return code: 10 (certificate has expired)
CONNECTED(016C)
depth=2 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary
Certification Authority
verify error:num=10:certificate has expired
notAfter=Jan 7 23:59:59 2004 GMT
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=**Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
When analyzing the cafile with the dumped certificates from Windows
certificate store, I found out that there are two certificates for Verisign
with identical subject, whereas one is expired, the other not.
X.509 Certificate Information:
Version: 1
Serial Number (hex): 00e49efdf33ae80ecfa5113e19a424**0232
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Wed Jan 07 23:59:59 UTC 2004
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Subject Public Key Algorithm: RSA
X.509 Certificate Information:
Version: 1
Serial Number (hex): 70bae41d10d92934b638ca7b03ccba**bf
Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Validity:
Not Before: Mon Jan 29 00:00:00 UTC 1996
Not After: Tue Aug 01 23:59:59 UTC 2028
Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary
Certification Authority
Subject Public Key Algorithm: RSA
Thus, it seems that openssl 0.9.8 just ignores the expired certificate and
searches if there is another valid one whereas openssl 1.0.0 stop with the
first expired certificate.
Is the new behavior the intended behavior? Is it possible to have the old
behavior also in new opensslversions?
Thanks
Klaus"
Is this behaviour intended in openssl-1.0.0 ?
--
Ashok
On Fri, Aug 3, 2012 at 3:28 AM, Dr. Stephen Henson wrote:
> On Thu, Aug 02, 2012, Ashok C wrote:
>
> > Hi,
> >
> > Is there a way in which I can determine the correct issuer certificate of
> > an issued certificate(either intermediate CA or end entity) based on
> > comparing immediate pair alone.
> > Eg:
> > My hierarchy is like this:
> >
> > Root
> > Intermediate CA 1
> > Intermediate CA 2
> > End entity
> >
> > Is it possible to determine that Intermediate CA2 is the issuer of the
> End
> > entity certificate without having to traverse the full hierarchy?
> >
> > I do not want to depend upon issuername-subjectname comparisons alone(As
> > this is not deterministic and conclusive).
> > I do not want to depend upon Authority Key Identifier /Subject Key
> > Identifier's keyId fields(As most CAs seem to not have this extension at
> > all)
> >
> > Basically I want some signature check method from openSSL can take two
> > certificates as input and tell me if one has issued the other:
> >
> > int openSSL_signature_check(X509* issuer_certificate, X509*
> > issued_certificate)
> > {
> > int return_code = signature_check(issuer_certificate,
> > issued_certificate)
> > if (0 == return_code)
> > return YES_ISSUER_IS_CORRECT;
> >else
> > return NO_ISSUER_IS_NOT_CORRECT;
> > }
> >
> > Is something like this already available in openSSL?
> >
>
> You can use the function X509_verify to do this but you have to extract the
> public key from the issuer using X509_get_pubkey.
>
> > One more question:
> > Given a certificate and trust store, openSSL's verify utility currently
> > returns OK in case the verification was successful. Is there a way in
> which
> > I can retrieve the formed and verified chain of certificates back?
> >
>
> There isn't a command line option to do this but the API call
> X509_STORE_CTX_get1_chain will retrieve the chain from an X509_STORE_CTX
> structure.
>
> 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: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Hi, I don't think this question was answered. Could you please reply? -- Ashok On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion < klaus.mailingli...@pernau.at> wrote: > Hi! > > I wrote a small program which dumps all root certificates from Windows > certificate store into a file. Then I use openssl to connect to Google and > validate its certificate: > > openssl s_client -connect www.google.com:443 -CAfile dump.crt > > When using openssl0.9.8k or openssl0.9.8x everything works as expected. > > When using openssl1.0.0g or openssl 1.0.1c the certificate validation > fails with: > Verify return code: 10 (certificate has expired) > > CONNECTED(016C) > depth=2 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary > Certification Authority > verify error:num=10:certificate has expired > notAfter=Jan 7 23:59:59 2004 GMT > verify return:0 > --- > Certificate chain > 0 s:/C=US/ST=California/L=**Mountain View/O=Google Inc/CN=www.google.com >i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA > 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA >i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification > Authority > > When analyzing the cafile with the dumped certificates from Windows > certificate store, I found out that there are two certificates for Verisign > with identical subject, whereas one is expired, the other not. > > X.509 Certificate Information: > Version: 1 > Serial Number (hex): 00e49efdf33ae80ecfa5113e19a424**0232 > Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary > Certification Authority > Validity: > Not Before: Mon Jan 29 00:00:00 UTC 1996 > Not After: Wed Jan 07 23:59:59 UTC 2004 > Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary > Certification Authority > Subject Public Key Algorithm: RSA > > X.509 Certificate Information: > Version: 1 > Serial Number (hex): 70bae41d10d92934b638ca7b03ccba**bf > Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary > Certification Authority > Validity: > Not Before: Mon Jan 29 00:00:00 UTC 1996 > Not After: Tue Aug 01 23:59:59 UTC 2028 > Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary > Certification Authority > Subject Public Key Algorithm: RSA > > > Thus, it seems that openssl 0.9.8 just ignores the expired certificate and > searches if there is another valid one whereas openssl 1.0.0 stop with the > first expired certificate. > > Is the new behavior the intended behavior? Is it possible to have the old > behavior also in new openssl versions? > > Thanks > Klaus > > __**__**__ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Sending again as the previous email did not appear in list. Is there some problem with the mailing list? -- Ashok On Wed, Sep 12, 2012 at 2:59 PM, Ashok C wrote: > Hi, > > I don't think this question was answered. Could you please reply? > > -- > Ashok > > > On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion < > klaus.mailingli...@pernau.at> wrote: > >> Hi! >> >> I wrote a small program which dumps all root certificates from Windows >> certificate store into a file. Then I use openssl to connect to Google and >> validate its certificate: >> >> openssl s_client -connect www.google.com:443 -CAfile dump.crt >> >> When using openssl0.9.8k or openssl0.9.8x everything works as expected. >> >> When using openssl1.0.0g or openssl 1.0.1c the certificate validation >> fails with: >> Verify return code: 10 (certificate has expired) >> >> CONNECTED(016C) >> depth=2 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary >> Certification Authority >> verify error:num=10:certificate has expired >> notAfter=Jan 7 23:59:59 2004 GMT >> verify return:0 >> --- >> Certificate chain >> 0 s:/C=US/ST=California/L=**Mountain View/O=Google Inc/CN=www.google.com >>i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA >> 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA >>i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification >> Authority >> >> When analyzing the cafile with the dumped certificates from Windows >> certificate store, I found out that there are two certificates for Verisign >> with identical subject, whereas one is expired, the other not. >> >> X.509 Certificate Information: >> Version: 1 >> Serial Number (hex): 00e49efdf33ae80ecfa5113e19a424**0232 >> Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary >> Certification Authority >> Validity: >> Not Before: Mon Jan 29 00:00:00 UTC 1996 >> Not After: Wed Jan 07 23:59:59 UTC 2004 >> Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary >> Certification Authority >> Subject Public Key Algorithm: RSA >> >> X.509 Certificate Information: >> Version: 1 >> Serial Number (hex): 70bae41d10d92934b638ca7b03ccba**bf >> Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary >> Certification Authority >> Validity: >> Not Before: Mon Jan 29 00:00:00 UTC 1996 >> Not After: Tue Aug 01 23:59:59 UTC 2028 >> Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary >> Certification Authority >> Subject Public Key Algorithm: RSA >> >> >> Thus, it seems that openssl 0.9.8 just ignores the expired certificate >> and searches if there is another valid one whereas openssl 1.0.0 stop with >> the first expired certificate. >> >> Is the new behavior the intended behavior? Is it possible to have the old >> behavior also in new openssl versions? >> >> Thanks >> Klaus >> >> __**__** >> __ >> OpenSSL Project http://www.openssl.org >> User Support Mailing Listopenssl-users@openssl.org >> Automated List Manager majord...@openssl.org >> > >
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Hi Etkal, >>s_client app or the OpenSSL cert store functionality that changed this. The problem is with the openSSL store itself, as I had tested this with my own SSL client and observed the same behaviour. -- Ashok On Thu, Sep 13, 2012 at 8:39 PM, Erik Tkal wrote: > I suppose that’s a workaround, but doesn’t address the root cause. > Windows can quite happily handle expired certificates still hanging out in > trusted stores; I see this all the time as root updates occur and renewed > certificates are installed. It seems that a change in OpenSSL broke the > previous behaviour that allowed this as well, though we can’t tell if it’s > the s_client app or the OpenSSL cert store functionality that changed this. > > > > > *Erik Tkal** > *Juniper OAC/UAC/Pulse Development > > > > ** ** > > *From:* owner-openssl-us...@openssl.org [mailto: > owner-openssl-us...@openssl.org] *On Behalf Of *Charles Mills > *Sent:* Thursday, September 13, 2012 9:42 AM > *To:* openssl-users@openssl.org > *Subject:* RE: certificate validation issues with openssl 1.0.0 and > expired certificates in cafile > > ** ** > > Would it make sense to delete the expired certificate from the Windows > store? Duplicate expired/non expired CA certificates sounds to me like a > problem waiting to happen. > > ** ** > > *Charles* > > *From:* owner-openssl-us...@openssl.org [ > mailto:owner-openssl-us...@openssl.org ] > *On Behalf Of *Ashok C > *Sent:* Thursday, September 13, 2012 12:49 AM > *To:* openssl-users@openssl.org > *Subject:* Re: certificate validation issues with openssl 1.0.0 and > expired certificates in cafile > > ** ** > > Sending again as the previous email did not appear in list. > Is there some problem with the mailing list? > > -- > Ashok > > On Wed, Sep 12, 2012 at 2:59 PM, Ashok C wrote: > > Hi, > > I don't think this question was answered. Could you please reply? > > -- > Ashok > > ** ** > > On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion < > klaus.mailingli...@pernau.at> wrote: > > Hi! > > I wrote a small program which dumps all root certificates from Windows > certificate store into a file. Then I use openssl to connect to Google and > validate its certificate: > > openssl s_client -connect www.google.com:443 -CAfile dump.crt > > When using openssl0.9.8k or openssl0.9.8x everything works as expected. > > When using openssl1.0.0g or openssl 1.0.1c the certificate validation > fails with: > Verify return code: 10 (certificate has expired) > > CONNECTED(016C) > depth=2 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary > Certification Authority > verify error:num=10:certificate has expired > notAfter=Jan 7 23:59:59 2004 GMT > verify return:0 > --- > Certificate chain > 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com >i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA > 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA >i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification > Authority > > When analyzing the cafile with the dumped certificates from Windows > certificate store, I found out that there are two certificates for Verisign > with identical subject, whereas one is expired, the other not. > > X.509 Certificate Information: > Version: 1 > Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232 > Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary > Certification Authority > Validity: > Not Before: Mon Jan 29 00:00:00 UTC 1996 > Not After: Wed Jan 07 23:59:59 UTC 2004 > Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary > Certification Authority > Subject Public Key Algorithm: RSA > > X.509 Certificate Information: > Version: 1 > Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf > Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary > Certification Authority > Validity: > Not Before: Mon Jan 29 00:00:00 UTC 1996 > Not After: Tue Aug 01 23:59:59 UTC 2028 > Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary > Certification Authority > Subject Public Key Algorithm: RSA > > > Thus, it seems that openssl 0.9.8 just ignores the expired certificate and > searches if there is another valid one whereas openssl 1.0.0 stop with the > first expired certificate. > > Is the new behavior the intended behavior? Is it possible to have the old > behavior also in new openssl versions? > > Thanks > Klaus > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > > ** ** > > ** ** >
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Gentle reminder .. Just want to know if this is a bug or intended behaviour. -- Ashok On Fri, Sep 14, 2012 at 3:12 PM, Ashok C wrote: > Hi Etkal, > > >>s_client app or the OpenSSL cert store functionality that changed this. > The problem is with the openSSL store itself, as I had tested this with my > own SSL client and observed the same behaviour. > > -- > Ashok > > On Thu, Sep 13, 2012 at 8:39 PM, Erik Tkal wrote: > >> I suppose that’s a workaround, but doesn’t address the root cause. >> Windows can quite happily handle expired certificates still hanging out in >> trusted stores; I see this all the time as root updates occur and renewed >> certificates are installed. It seems that a change in OpenSSL broke the >> previous behaviour that allowed this as well, though we can’t tell if it’s >> the s_client app or the OpenSSL cert store functionality that changed this. >> >> >> >> >> *Erik Tkal** >> *Juniper OAC/UAC/Pulse Development >> >> >> >> ** ** >> >> *From:* owner-openssl-us...@openssl.org [mailto: >> owner-openssl-us...@openssl.org] *On Behalf Of *Charles Mills >> *Sent:* Thursday, September 13, 2012 9:42 AM >> *To:* openssl-users@openssl.org >> *Subject:* RE: certificate validation issues with openssl 1.0.0 and >> expired certificates in cafile >> >> ** ** >> >> Would it make sense to delete the expired certificate from the Windows >> store? Duplicate expired/non expired CA certificates sounds to me like a >> problem waiting to happen. >> >> ** ** >> >> *Charles* >> >> *From:* owner-openssl-us...@openssl.org [ >> mailto:owner-openssl-us...@openssl.org ] >> *On Behalf Of *Ashok C >> *Sent:* Thursday, September 13, 2012 12:49 AM >> *To:* openssl-users@openssl.org >> *Subject:* Re: certificate validation issues with openssl 1.0.0 and >> expired certificates in cafile >> >> ** ** >> >> Sending again as the previous email did not appear in list. >> Is there some problem with the mailing list? >> >> -- >> Ashok >> >> On Wed, Sep 12, 2012 at 2:59 PM, Ashok C wrote: >> >> Hi, >> >> I don't think this question was answered. Could you please reply? >> >> -- >> Ashok >> >> ** ** >> >> On Tue, Jul 31, 2012 at 11:13 PM, Klaus Darilion < >> klaus.mailingli...@pernau.at> wrote: >> >> Hi! >> >> I wrote a small program which dumps all root certificates from Windows >> certificate store into a file. Then I use openssl to connect to Google and >> validate its certificate: >> >> openssl s_client -connect www.google.com:443 -CAfile dump.crt >> >> When using openssl0.9.8k or openssl0.9.8x everything works as expected. >> >> When using openssl1.0.0g or openssl 1.0.1c the certificate validation >> fails with: >> Verify return code: 10 (certificate has expired) >> >> CONNECTED(016C) >> depth=2 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary >> Certification Authority >> verify error:num=10:certificate has expired >> notAfter=Jan 7 23:59:59 2004 GMT >> verify return:0 >> --- >> Certificate chain >> 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com >>i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA >> 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA >>i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification >> Authority >> >> When analyzing the cafile with the dumped certificates from Windows >> certificate store, I found out that there are two certificates for Verisign >> with identical subject, whereas one is expired, the other not. >> >> X.509 Certificate Information: >> Version: 1 >> Serial Number (hex): 00e49efdf33ae80ecfa5113e19a4240232 >> Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary >> Certification Authority >> Validity: >> Not Before: Mon Jan 29 00:00:00 UTC 1996 >> Not After: Wed Jan 07 23:59:59 UTC 2004 >> Subject: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary >> Certification Authority >> Subject Public Key Algorithm: RSA >> >> X.509 Certificate Information: >> Version: 1 >> Serial Number (hex): 70bae41d10d92934b638ca7b03ccbabf >> Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary >>
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Hi,
One more observation was made here in another test case.
*Configuration:*
One old root CA certificate oldca.pem with subject name say, C=IN
One new root CA certificate newca.pem with same subject name.
One EE certificate, ee.pem issued by new root CA.
*Test case 1:*
Using CAFile option in openssl verify of the ee.pem,
If oldca.pem is placed on top and newca.pem below, verification fails.
i.e., cat oldca.pem > combined.pem;cat newca.pem >> combined.pem
*Test case 2:*
If newca.pem is placed on top and oldca.pem below that, verification
succeeds.
i.e., cat newca.pem > combined.pem; cat oldca.pem>>combined.pem
Test case 1 does not seem to correct behaviour as the trust store contains
newca.pem. Ideally the lookup needs to verify ee.pem with the newca.pem.
P.S. The CA and EE certificates are v3 but do not contain AKI or SKI fields.
--
Ashok
On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm wrote:
> On 9/13/2012 3:41 PM, Charles Mills wrote:
>
>> Would it make sense to delete the expired certificate from the Windows
>> store? Duplicate expired/non expired CA certificates sounds to me like a
>> problem waiting to happen.
>>
>> /Charles/
>>
>>
>>
> Windows has built in support for using and checking time stamping
> countersignatures in PKCS7 signatures. If the countersignature is signed
> with a currently valid certificate with the time stamping
> extended usage enabled, then the outer PKCS7 signature and its certificate
> is checked as if the current time was the one certified
> by the time stamp (but still using up to date revocation
> information, paying attention to revocation reasons and dates).
>
> Thus the Windows certificate store has good reason to keep around
> expired CA certificates going back to ca. 1996 (when Microsoft
> released the first version supporting time stamped signatures).
>
> P.S.
>
> I see no technical reason why such time stamp countersignature
> support could not be added to the OpenSSL core code.
>
> The validation side implementation involves a few standard OIDs
> (1.3.6.1.5.5.7.3.8 = timeStamping extended key usage, 1.2.840.113549.1.9.6
> = counterSignature
> unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
> authenticated attribute). The countersignature specifies the
> signed data type to be "1.2.840.113549.1.7.1=data", but the
> signed data is really the encryptedDigest/signatureValue from
> the enclosing SignerInfo being countersigned (as per
> PKCS#9/RFC2985 section 5.3.6). The timeStamp indicated by
> a counterSignature made by an entity with the timeStamping
> extended key usage is simply the standard signingTime
> authenticated attribute in the counterSignature itself.
>
> On the signing side, the signer simply submits his
> encryptedDigest/signatureValue to a time stamping service he has
> a contract with, using a simplified historic protocol as follows:
>
> POST url with "Accept: application/octet-string" "Content-Type:
> application/octet-string" The post data is Base64 of DER of
>SEQUENCE { -- Attribute
> type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
> SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
> content Type OID -- must be 1.2.840.113549.1.7.1 =data
> content [0] EXPLICIT OCTET STRING
> -- must be the outer encryptedDigest
> }
> }
> }
>
> Response if successful is a 200 HTTP status with "Content-Type:
> application/octet-string" and a value which is Base64 of DER of
> a PKCS#7/CMS SignedData where encapContentInfo is the ContentInfo
> from the request. The time is indicated by the standard
> signingTime authenticated attribute in the only SignerInfo in
> signerInfos)
>
> This historic time stamping protocol is necessary because the
> RFC3161 protocol returns a signature which is not a valid RFC2985
> counterSignature.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
> Transformervej 29, 2730 Herlev, 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
>
>
> __**__**__
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Only the private and public keys are different.. Rest of the fields are
same.. Basically I am simulating the trust anchor update related scenarios..
And yes Jacob, thanks for indicating, I'll make sure I don't use such
abbreviations from here on..
Ashok
On Sep 24, 2012 11:25 PM, "Jakob Bohm" wrote:
> Hi,
>
> In your test case which fields actually differ between the
> old root CA certificate and the new root CA certificate?
>
> P.S.
>
> Please do not use those 3 letter abbreviations of certificate
> field names, very few people know those abbreviations.
>
> For the benefit of other readers:
>
> I think Ashok was referring to AuthorityKeyIdentifier and
> SubjectKeyIdentifier fieldsbeing absent from the root
> CA certificates in his scenario.
>
> On 9/24/2012 6:26 PM, Ashok C wrote:
>
>> Hi,
>>
>> One more observation was made here in another test case.
>> _*Configuration:*_
>> One old root CA certificate oldca.pem with subject name say, C=IN
>> One new root CA certificate newca.pem with same subject name.
>> One EE certificate, ee.pem issued by new root CA.
>>
>> _*Test case 1:*_
>> Using CAFile option in openssl verify of the ee.pem,
>> If oldca.pem is placed on top and newca.pem below, verification fails.
>> i.e., cat oldca.pem > combined.pem;cat newca.pem >> combined.pem
>>
>> _*Test case 2:*_
>> If newca.pem is placed on top and oldca.pem below that, verification
>> succeeds.
>> i.e., cat newca.pem > combined.pem; cat oldca.pem>>combined.pem
>>
>> Test case 1 does not seem to correct behaviour as the trust store
>> contains newca.pem. Ideally the lookup needs to verify ee.pem with the
>> newca.pem.
>>
>> P.S. The CA and EE certificates are v3 but do not contain AKI or SKI
>> fields.
>>
>> --
>> Ashok
>>
>>
>> On Mon, Sep 24, 2012 at 6:50 PM, Jakob Bohm > <mailto:jb-open...@wisemo.com>**> wrote:
>>
>> On 9/13/2012 3:41 PM, Charles Mills wrote:
>>
>> Would it make sense to delete the expired certificate from the
>> Windows
>> store? Duplicate expired/non expired CA certificates sounds to
>> me like a
>> problem waiting to happen.
>>
>> /Charles/
>>
>>
>>
>> Windows has built in support for using and checking time stamping
>> countersignatures in PKCS7 signatures. If the countersignature is
>> signed with a currently valid certificate with the time stamping
>> extended usage enabled, then the outer PKCS7 signature and its
>> certificate is checked as if the current time was the one certified
>> by the time stamp (but still using up to date revocation
>> information, paying attention to revocation reasons and dates).
>>
>> Thus the Windows certificate store has good reason to keep around
>> expired CA certificates going back to ca. 1996 (when Microsoft
>> released the first version supporting time stamped signatures).
>>
>> P.S.
>>
>> I see no technical reason why such time stamp countersignature
>> support could not be added to the OpenSSL core code.
>>
>> The validation side implementation involves a few standard OIDs
>> (1.3.6.1.5.5.7.3.8 = timeStamping extended key usage,
>> 1.2.840.113549.1.9.6 = counterSignature
>> unauthenticated attribute and 1.2.840.113549.1.9.5 signingTime
>> authenticated attribute). The countersignature specifies the
>> signed data type to be "1.2.840.113549.1.7.1=data", but the
>> signed data is really the encryptedDigest/signatureValue from
>> the enclosing SignerInfo being countersigned (as per
>> PKCS#9/RFC2985 section 5.3.6). The timeStamp indicated by
>> a counterSignature made by an entity with the timeStamping
>> extended key usage is simply the standard signingTime
>> authenticated attribute in the counterSignature itself.
>>
>> On the signing side, the signer simply submits his
>> encryptedDigest/signatureValue to a time stamping service he has
>> a contract with, using a simplified historic protocol as follows:
>>
>> POST url with "Accept: application/octet-string" "Content-Type:
>> application/octet-string" The post data is Base64 of DER of
>> SEQUENCE { -- Attribute
>>type OID -- must be 1.3.6.1.4.1.311.3.2.1 =timeStampRequest
>>SEQUENCE { -- This is a PKCS#7 ContentInfo, see RFC2315
>> content Type OID -- must be 1.2.840.
Re: certificate validation issues with openssl 1.0.0 and expired certificates in cafile
Thanks Jacob, but in the three scenarios you mentioned, the first one *does not* seem to be supported by openssl 1.0.0*. I think that was the subject of this email thread in the beginning. >>1. Changing expiry or other attributes while keeping the key. Here the CA issues a new self-signed certificate with updated attributes but unchanged key. Here, if the expired one is encountered first, openSSL does not lookup the non-expired CA certificate. This is then a bug right? -- Ashok On Tue, Sep 25, 2012 at 12:33 AM, Jakob Bohm wrote: > Does that work with any other serious X.509 validation toolkit? > > To make this work (assuming the old root CA cert has not yet expired), the > validation code will need to actually verify the End Entity > certificate against both public keys, which effectively reduces the > algorithm security by allowing twice as many bit strings to be > accepted as valid. > > Filtering based on criteria that do not involve actual signature > validation would be cryptographically safe, but when falling back to > validating against multiple signatures, extra care is needed for the > above reason. > > As for trust anchor update scenarios, I know of 3 different scenarios > that should be accepted by any good X.509 validation algorithm: > > 1. Changing expiry or other attributes while keeping the key. > Here the CA issues a new self-signed certificate with updated > attributes but unchanged key. > > 2. Changing the CA key when the old key has *not* been compromised. > Here the CA generates a new key and issues two certificates for it: > >A. A self-signed new root with a serial number or other variation > in one of the subject name components. >B. A certificate for the new key and the same subject and (optional) > SubjectKeyIdentifier as A, but issued by the old root certificate > identity and key. > > End Entities with certificates issued with the new key reference the > modified subject as authority and should be configured to supply the > transitional "B" certificate in chains sent to other end entities. > Such end entities should then succeed validating against either the > old root CA (via the B certificate supplied) or the new root CA > (via finding it as a locally configured trust anchor). > > This is the scenario used by at least one major CA for its upgrade > to larger keys, and SSL servers that forget the B certificate in > the supplied chain get rejected by at least one common platform > version (Android 2.3) because it only includes the old trust > root in its store and uses an underdocumented BouncyCastly store > format thus preventing the efficient deployment of the new A cert. > > 3. Setting up the CA to have keys for more than one algorithm (such > as RSA 1024 with SHA1 and RSA 4096 with SHA256). In this case, the > certificate validation could SHOULD (but might not) match issued end > entity certificates to the trust anchor by also comparing > signatureAlgorithm in the issued certificate against > subjectPublicKeyInfo.algorithm in the candidate issuer cert from the > store. > > However because not all clients are going to do that, it is still > recommended that the CA follows the scenario 2 procedures, except > when it is a test CA for verifying handling of this scenario in > X.509 implementations. > > > On 9/24/2012 8:01 PM, Ashok C wrote: > >> Only the private and public keys are different.. Rest of the fields are >> same.. Basically I am simulating the trust anchor update related >> scenarios.. >> And yes Jacob, thanks for indicating, I'll make sure I don't use such >> abbreviations from here on.. >> >> Ashok >> >> On Sep 24, 2012 11:25 PM, "Jakob Bohm" > <mailto:jb-open...@wisemo.com>**> wrote: >> >> Hi, >> >> In your test case which fields actually differ between the >> old root CA certificate and the new root CA certificate? >> >> P.S. >> >> Please do not use those 3 letter abbreviations of certificate >> field names, very few people know those abbreviations. >> >> For the benefit of other readers: >> >> I think Ashok was referring to AuthorityKeyIdentifier and >> SubjectKeyIdentifier fieldsbeing absent from the root >> CA certificates in his scenario. >> >> On 9/24/2012 6:26 PM, Ashok C wrote: >> >> Hi, >> >> One more observation was made here in another test case. >> _*Configuration:*_ >> One old root CA certificate oldca.pem with subject name say, C=IN >> One new root CA certificate newca.pem with same subject name. >>
Re: How to over-ride SSL_CTX_use_PrivateKey_file() behavior with custom engine
Thanks Steve and Kent for the pointers. Makes things clear for now. On Thu, Dec 6, 2012 at 4:22 AM, Dr. Stephen Henson wrote: > On Wed, Dec 05, 2012, Ashok C wrote: > > > Hi, > > > > Our current SSL server loads plain-text private keys using the > > SSL_CTX_use_PrivateKey_file() > > method. We are moving from this strategy to use custom encrypted private > > keys using the TPM concept. For this, we have an engine implemented. Now > > the question is this. > > > > Does my SSL server need to change from loading private keys using > > SSL_CTX_use_PrivateKey_file() > > method to use this method --> ENGINE_load_private_key(ENGINE *e, const > char > > *key_id, > > > > UI_METHOD *ui_method, void *callback_data) > > > > > > You can't use SSL_CTX_use_PrivateKey_file to load an ENGINE specific key. > Instead you use ENGINE_load_private_key() to load the key into an EVP_PKEY > structure and then pass that to SSL_CTX_use_PrivateKey(). > > 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: Certificate expiry alarms Reg.
Thanks Jeff, My response inline. On Thu, Feb 14, 2013 at 5:31 PM, Jeffrey Walton wrote: > On Thu, Feb 14, 2013 at 5:58 AM, Ashok C wrote: > > Hi, > > > > As part of implementing certificate expiry related alarms for my SSL > > application, I would kindly require few suggestions and clarifications > from > > the community. > Does that include OSCP checking? On a continuous basis? The CA will > not warrant a certificate if its on a CRL. It does not matter when you > get the list. > Did you mean OCSP? If yes, no. I'm not considering OCSP. Also, currently I'm not considering CRLs also. > > > 1. What are the different allowed time zones in a certificate? As per the > > RFC, I understand that only GMT and Generalized time are allowed, but > can I > > consider this as a mandate? I remember seeing certificates containing the > > date information in other time zones, so wanted to confirm this. > Time Zones are strictly presentation. The only time is GMT or UTC. It > does not matter if its the fellow in the bearskin hat looking up at > noon or an atomic clock. > Ok, that's good news :) > > > 2. I was planning to implement midnight check for certificate expiry. But > > can this be a problem? As I understand, certificates need not expire at > > midnight but basically at any point of time. > The CA will not warrant a certificate if its beyond notAfter. > Yes, I got this point. So ideally I should raise the alarm then and there I guess. Right? > > > Let us say the end entity certificate expires at 12:00:01 AM, so my > expiry > > alarm will be raised potentially after 23:59:59 hours. > > What is the impact of me not raising this alarm immediately? And I would > > want to understand the impact to both a server application as well as a > > client application separately. In my point of view, server/client will > not > > be able to establish SSL connections during this time period(~24 hours), > but > > how big would be this impact? > > There are two hidden issues: (1) what precisely is warranted, and (2) > what liability is in play. Good luck in pinning a CA on liability (100 > page plus CPSs). > Not clear what you exactly meant here. Could you please put it in more simpler terms? Thanks. > > Jeff > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Re: Certificate expiry alarms Reg.
Thanks a lot Jeff, The book is really very useful. On Sun, Feb 24, 2013 at 12:36 AM, Jeffrey Walton wrote: > On Fri, Feb 15, 2013 at 9:25 AM, Ashok C wrote: > > On Thu, Feb 14, 2013 at 5:31 PM, Jeffrey Walton > wrote: > >> On Thu, Feb 14, 2013 at 5:58 AM, Ashok C wrote: > >> > > >> > As part of implementing certificate expiry related alarms for my SSL > >> > application, I would kindly require few suggestions and clarifications > >> > from the community. > >> ... > >> > >> There are two hidden issues: (1) what precisely is warranted, and (2) > >> what liability is in play. Good luck in pinning a CA on liability (100 > >> page plus CPSs). > > > > Not clear what you exactly meant here. Could you please put it in more > > simpler terms? Thanks. > >> > Read the chapter on PKI from Peter Gutmann's Security Engineering (pp. > 595-650, www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). > > It's not dry reading. Its interesting from a technical POV (what's the > problem, how is it being solved); from a historical POV (committee > disagreements, past failures, etc); and it's somewhat humorous at > times (Gutmann has a witty sense of humor). > > Jeff >
Using openssl for AS2 [I]
Classification: For internal use only Hi, I am using openssl - "OpenSSL 0.9.8e 23 Feb 2007" on Solaris. I need to use this to decrypt and verify AS2 messages coming in from customers. Is this possible ? I do not see a "cms" option available. When I use openssl smime -verify -CAfile -out , the verification is successful but the output contains the Content-Type, Content-Transfer-Encoding and Content-Disposition Headers. How do I get around this issue ? Thanks and Regards, Dwipin Chandran. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: Using openssl for AS2 [I]
Classification: For internal use only Thanks Jakob. Do you have any pointers around "script that decodes the Content-Transfer-Encoding" ? Is there something that is widely used ? Thanks and Regards, Dwipin Chandran. From: Jakob Bohm To: openssl-users@openssl.org, Date: 04/04/2013 11:02 PM Subject: Re: Using openssl for AS2 [I] On 4/4/2013 9:00 AM, Dwipin C wrote: > Classification: For internal use only > > Hi, > > I am using openssl - "OpenSSL 0.9.8e 23 Feb 2007" on Solaris. I need to > use this to decrypt and verify AS2 messages coming in from customers. Is > this possible ? OpenSSL 0.9.8e is an old insecure version, please upgrade to the latest security upgrade, either version 0.9.8y (contains only security fixes), 1.0.0k (contains 1.0.0 features and security fixes) or 1.0.1e (contains 1.0.0 features, 1.0.1 features and security fixes). > > I do not see a "cms" option available. The cms command is a version 1.0.0 and later feature, upgrade to 1.0.0k, 1.0.1e or use the smime command. > > When I use openssl smime -verify -CAfile -out , > the verification is successful but the output contains the Content-Type, > Content-Transfer-Encoding and Content-Disposition Headers. > > How do I get around this issue ? Just filter the result through a simple script that removes those headers and decodes the Content-Transfer-Encoding. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, 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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Use of no-deprecated for VC-WIN32 configuration
Hey all,
So having read the NEWS announcement for 0.9.8, I was eager to try
re-compiling openssl without the old deprecated functionality. However,
util\mk1mf.pl complains about no-deprecated being an unknown option.
My system setup is as follows:
OS: WinXP SP2
Perl: ActiveState 5.8.4 build 810
Compiler: MS Visual Studio .NET 2002
Here's the steps I took:
1. Extracted openssl-0.9.8.tar.gz to C:\openssl-0.9.8.
2. cd /d C:\openssl-0.9.8.
3. perl Configure no-deprecated VC-WIN32
4. ms\do_nasm.bat
The output for step 4 is as follows:
{{{
Generating x86 for NASM assember
Bignum
DES
"crypt(3)"
Blowfish
CAST5
RC4
MD5
SHA1
RIPEMD160
RC5\32
C:\openssl-0.9.8>perl util\mkfiles.pl 1>MINFO
C:\openssl-0.9.8>perl util\mk1mf.pl nasm VC-WIN32 1>ms\nt.mak
unknown option - no-deprecated
C:\openssl-0.9.8>perl util\mk1mf.pl dll nasm VC-WIN32 1>ms\ntdll.mak
unknown option - no-deprecated
C:\openssl-0.9.8>perl util\mk1mf.pl nasm BC-NT 1>ms\bcb.mak
unknown option - no-deprecated
C:\openssl-0.9.8>perl util\mkdef.pl 32 libeay 1>ms\libeay32.def
C:\openssl-0.9.8>perl util\mkdef.pl 32 ssleay 1>ms\ssleay32.def
}}}
If I build openssl normally without the no-deprecated option, then the
Configure, do_nasm.bat, nmake steps all complete successfully.
Any advice on how to get no-deprecated working for VC-WIN32 environments?
TIA
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: certificate embedded into the executable
Theoretically it's possible to embed certificates into a Windows and Linux executables - not sure about other architectures though. In my spare time I've been researching this topic as well. You can use the ImageAddCertificate() Win32 API from Imagehlp.dll to programmatically store a certificate inside of an executable. I'm not sure what format the certificate has to be in, but knowing Micro$oft it whould have to be PKCS#7 or is it #12? - I forget which now. As for Linux, it's possible to create another data segment and store the certificate into that. In either architecture, OpenSSL will not be able to read directly from the executable image. You will need to develop a way to programmatically extract from the executable image the certificate as binary data blob (see the other APIs Imagehlp.dll exports) and supply it to openssl via an in-memory BIO. I hope this gives you some pointers on where to look next though. Hi, Can anyone tell me if it's possible to embed a client certificate inside my executable, and what calls I should use to tell OpenSSL to use it? I think I'll also need to do it for the CA, since we use self-signed certificates, and I want the client to verify the server's certificate too. Thanks, ;) james. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Encrypting data using X509 cert...
I have a problem that I am working on. I am certain there must be a simple way to do it but I haven't yet discovered it in the docs yet. I am hoping someone can point me in the correct direction. BTW, this is a programming issue so using a command line function isn't useful. I have an X509 certificate and a pointer to a data buffer. Using the X509 cert and given a pre-determined block-chaining cipher (from the Openssl collection) I need to encrypt and decrypt the contents of the buffer. Can anyone assist me? Thanks in advance, Chuck __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Openssl on Suse 10 x86-64
Hi, I am running openssl 0.9.8. I have code to verify signature The code works fine on about every major Unix platform. However, they are all 32-bit platforms. When I tried to run it on Suse Linux x86-64 machines it failed. I have set my target to linux-x86_64 and turned off assembly with "no_asm" option and also changed options for this target to "-O0" from "-O3". Still couldn't get it to work. Does anyone know how well this code works on 64-bit platforms, and if there are any patches needed Thanks,Terry
Re: Openssl on Suse 10 x86-64
My error, to be exact, came from an xmlsec signature check call on a SAML token. Xmlsec is also freeware. Most feedback I got from other lists appeared to point the problem at openssl. I am sure 0.9.7d works fine. In fact both Redhat and Suse released RPMs on openssl for 64 bit machines up to openssl 0.9.7g. This is over an year old. Is there any reason no RPMs released on 0.9.8 or newer? Thanks, Terry On 7/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I'm not sure about 0.9.8 yet, but 0.9.7d works well on the x86_64 platforms. we use no_asm no_idea no_rc5 threads shared. what exactly is the failure? Dave McLellan --Consulting Software Engineer - SPEA Engineering EMC Corporation 228 South St. Mail Stop: 228 LL/AA-24 Hopkinton, MA 01748 USA +1-508-249-1257 F: +1-508-497-8030 [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of T CSent: Monday, July 24, 2006 4:55 PMTo: openssl-users@openssl.orgSubject: Openssl on Suse 10 x86-64 Hi, I am running openssl 0.9.8. I have code to verify signature The code works fine on about every major Unix platform. However, they are all 32-bit platforms. When I tried to run it on Suse Linux x86-64 machines it failed. I have set my target to linux-x86_64 and turned off assembly with "no_asm" option and also changed options for this target to "-O0" from "-O3". Still couldn't get it to work. Does anyone know how well this code works on 64-bit platforms, and if there are any patches needed Thanks,Terry
"openssl req" SSL/SSH key merge
Are there any downstream problems using a cert based off of a ssh-keygen as opposed to an "openssl genrsa"? For example: ssh-keygen -trsa -b1024 -ftestid_rsa -N "" openssl req -new -key testid_rsa -out testid_rsa.csr The above is what I'm currently using based off OpenSSH's supported x.509 (Roumen Petrov) and it appears to look promising. In other words would authenticate, encryption, digital signatures, etc. certificate operations be normal without an OpenSSL based key? Just looking for a way to "merge" the environments if possible on a single key... Thx, cs __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Security Hole - RSA 2?
Is RSA ver 2 (SSH) compatiblity with SSL by design or a given fact? I haven't found any references anywhere addressing this or any security concern. In addition, are there any downstream problems using a cert based off of a ssh-keygen as opposed to an "openssl genrsa"? For example: ssh-keygen -trsa -b1024 -ftestid_rsa -N "" openssl req -new -key testid_rsa -out testid_rsa.csr Has anyone experimented with this? It appears to work and looks promising. In other words would authenticate, encryption, digital signatures, etc. certificate operations be normal without an OpenSSL based key? Just looking for a way to "merge" the environments if possible on a single key and not utilize a hole... Thx, cs __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Generating a lot of randomness...
I have to generate quite a few random keys (and iv's) during a days. It comes out to about 1 million keys (16 bytes each) and 1 million iv's (16 bytes each). I tried using /dev/random and /dev/urandom but in one case it blocks too much of the time and in the other seems to run pretty slow. I tried using EGAD et al to no avail. So I decided to take a different approach. I am hoping to hear from others how they might have solved the problem. I thought I would take a hash of the message and using it as the salt call EVP_BytesToKey. I was wondering what others think of this solution. Chuck Wegrzyn Open Intent, Inc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Generating a lot of randomness...
I can't add anything beyond what is available on a AMD or Intel motherboard. So is there a built-in HRNG that I can get to (if so, where is the driver for it)? Thanks again, Chuck Wegrzyn Ken Goldman wrote: >>Date: Thu, 23 Jun 2005 12:22:30 -0400 >>From: C Wegrzyn <[EMAIL PROTECTED]> >> >>I have to generate quite a few random keys (and iv's) during a days. It >>comes out to about 1 million keys (16 bytes each) and 1 million iv's (16 >>bytes each). >> >>I tried using /dev/random and /dev/urandom but in one case it blocks too >>much of the time and in the other seems to run pretty slow. I tried >>using EGAD et al to no avail. So I decided to take a different >>approach. I am hoping to hear from others how they might have solved >>the problem. >> >>I thought I would take a hash of the message and using it as the salt >>call EVP_BytesToKey. I was wondering what others think of this solution. >> >> > >I've seen this approach: Use the hardware random number generator HRNG >to seed a pseudorandom number generator PSRG. Use PSRG to generate >random numbers. Each n random numbers, reseed PSRG from HRNG. > > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Generating a lot of randomness...
Generating one or two random numbers over a period of time isn't a big deal. Generating 100,000+ 128 bit random numbers an hour taxes /dev/random and /dev/urandom. Even the use of EGAD doesn't help. If you re-read the thread you will see that I wrote what I thought was a reasonable approach and looking for concrete criticism of it or other ways. C David Schwartz wrote: >>I can't add anything beyond what is available on a AMD or Intel >>motherboard. So is there a built-in HRNG that I can get to (if so, where >>is the driver for it)? >> >> > > Use /dev/urandom to seed your own PRNG. Or use it to seed OpenSSL's > PRNG. > > Why are you asking on this list anyway? Did you try OpenSSL's PRNG and > find >it insufficient? > > DS > > >__ >OpenSSL Project http://www.openssl.org >User Support Mailing Listopenssl-users@openssl.org >Automated List Manager [EMAIL PROTECTED] > > > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Generating a lot of randomness...
I see things for adding entropy, loading files, etc. I don't see anything about generating random numbers. Am I missing something so obvious if it was a snake it would have bitten me by now? Chuck Wegrzyn David Schwartz wrote: >>Generating one or two random numbers over a period of time isn't a big >>deal. Generating 100,000+ 128 bit random numbers an hour taxes >>/dev/random and /dev/urandom. Even the use of EGAD doesn't help. >> >> > > Right. > > > >>If you re-read the thread you will see that I wrote what I thought was a >>reasonable approach and looking for concrete criticism of it or >>other ways. >> >> > > But why not the obvious approach -- using OpenSSL's RNG? > > DS > > >__ >OpenSSL Project http://www.openssl.org >User Support Mailing Listopenssl-users@openssl.org >Automated List Manager [EMAIL PROTECTED] > > > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Generating a lot of randomness...
Linux (gentoo variant). C. Ted Mittelstaedt wrote: > > >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] Behalf Of C Wegrzyn >>Sent: Thursday, June 23, 2005 10:14 AM >>To: Ken Goldman >>Cc: openssl-users@openssl.org >>Subject: Re: Generating a lot of randomness... >> >> >>I can't add anything beyond what is available on a AMD or Intel >>motherboard. So is there a built-in HRNG that I can get to (if so, where >>is the driver for it)? >> >> >> > >What operating system are you using? > >Ted > >__ >OpenSSL Project http://www.openssl.org >User Support Mailing Listopenssl-users@openssl.org >Automated List Manager [EMAIL PROTECTED] > > > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
semiOT: SSL + apache + php
Hi there.. I was trying to figure how to compile apache 1.3.12 with php4 support and apache-SSL 1.39 I expand apache 1.3.12 src, php4 and open-SSL 0.9.5a I configure first php. Then, compile open-SSL with no problems. the next step I do is expanding the apache 1.3.12+ssl-1.39 patch in the apache src directory and apply it again with no problems. Finally, when I compile apache I get the next error: I have already set the SSL_BASE env var.. but does it have to have the path to the open-SSL source or the compiled version?? here is what make says: [...] apache_ssl.c:61: openssl/ssl.h: No such file or directory apache_ssl.c:62: openssl/err.h: No such file or directory apache_ssl.c:63: openssl/x509.h: No such file or directory apache_ssl.c:64: openssl/pem.h: No such file or directory apache_ssl.c:65: openssl/crypto.h: No such file or directory apache_ssl.c:66: openssl/rand.h: No such file or directory apache_ssl.c:99: #error SSLeay versions below 0.8.x are no longer supported make[4]: *** [apache_ssl.o] Error 1 Can you please help me?? (if I should not be posting this in the open-ssl list, please tell me where I can, thanks) TIA Sam __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
server not responfing
Hi there.. I (like most humans) have some problems in my life.. I'm not
expecting you to help me solve all of them, but surely will do with this
one:
I'm using
Linux RedHat6.1
apache 1.3.12
open-SSL 0.9.5a
mod_ssl-2.6.2-1.3.12
all compiled, installed and apparently working fine.
I generate the server certs:
openssl genrsa -des3 (-rand /dev/random) -out php.key 1024
openssl req -new -key php.key -out php.csr
openssl x509 -req -days 30 -in php.csr -signkey php.key -out php.crt
I include the paths to certificate and key in the apache httpd.conf
inside a ssl virtual host definition.. but the whole thing doesn't work
at all..
I restart httpd, and all goes ok
I get this in the apache error log:
[notice] Apache/1.3.12 (Unix) PHP/4.0b3 mod_ssl/2.6.2 OpenSSL/0.9.5a
configured -- resuming normal operations
[notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
and this in the ssl_engine log:
[info] Server: Apache/1.3.12, Interface: mod_ssl/2.6.2, Library:
OpenSSL/0.9.5a
[info] Init: 1st startup round (still not detached)
[info] Init: Initializing OpenSSL library
[info] Init: Seeding PRNG with 136 bytes of entropy
[info] Init: Generating temporary RSA private keys (512/1024 bits)
[info] Init: Configuring temporary DH parameters (512/1024 bits)
[info] Init: 2nd startup round (already detached)
[info] Init: Reinitializing OpenSSL library
[trace] Inter-Process Session Cache (DBM) Expiry: old: 0, new: 0,
removed: 0
[info] Init: Seeding PRNG with 136 bytes of entropy
[info] Init: Configuring temporary RSA private keys (512/1024 bits)
[info] Init: Configuring temporary DH parameters (512/1024 bits)
[info] Init: Initializing (virtual) servers for SSL
this is what I have in the SSL section of my httpd.conf:
DocumentRoot "/home/http/php/"
ServerName php
ServerAdmin root@localhost
ErrorLog logs/securephp_error_log
TransferLog logs/securephp_access_log
SSLEngine on
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/httpd/conf/ssl.crt/php.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/php.key
SSLVerifyClient 0
#SSLVerifyDepth 10
SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars
SSLOptions +StdEnvVars
SSLOptions +StdEnvVars +FakeBasicAuth +ExportCertData
+CompatEnvVars
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
when I try co connect from a browser to https://php or http://php:443 I
get no response from server..
I have a standard apache virtual host definition of the site php, and
another one inside SSL part called as you may have seen above php_:443.
Is this correct? can I do this? (a secure and not secure virtual host
called the same way and pointing to the same directory tree)
I have: SSLVerifyClient 0 in my httpd.conf so that a client cert it's
not required ,, Am I wrong?
maybe the problem is that I have no client cert.. how can I generate and
install it in my browsers (netscape navigator and iexplorer)
but I think if the problem were that, I would obtain some output in my
http/ssl log files..
Can you please help me?
Thanks very much
Sam at igmweb dot com
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
What is the easiest way to get total bytes of ALL SSL packets?
What is the easiest way to get total bytes of ALL SSL packets (incoming & outgoing @ the client side) for receiving one single file via SSL? (i.e. original file size + SSL overhead) The original file is about 50K. What should be the overhead in size? Can I do: s_client -debug -connect XXX.com:443 ... | grep "read from" read from 08089300 [080A3000] (7 bytes => 7 (0x7)) read from 08089300 [080A3007] (72 bytes => 72 (0x48)) read from 08089300 [080A3000] (5 bytes => 5 (0x5)) ... Then, add up all the bytes for INCOMING bytes. And, do s_client -debug -connect XXX.com:443 ... | grep "write to" Then add up all the bytes for OUTGOING bytes. Many thanks. __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: What is the easiest way to get total bytes of ALL SSL packets?
For serving a 46179-byte plain-text file in the following SSL session: Protocol : TLSv1 Cipher: EDH-RSA-DES-CBC3-SHA (Server public key is 1024 bit) 1. Before sending a "GET / HTTP/1.0" request, I got: SSL handshake has read 1225 bytes (i.e. 2.7% overhead), and written 314 bytes (i.e. 0.7% overhead). 2. After sending a "GET" request, I got 47786 "read from" bytes (i.e. 3.5% overhead), and 433 "write to" bytes (i.e. 0.9% overhead). (See below for how I get "read from" & "write to" bytes) Does it look about right? Please advise. --- t c <[EMAIL PROTECTED]> wrote: > What is the easiest way to get total bytes of ALL SSL packets > (incoming & outgoing @ the client side) for receiving one single > file via SSL? (i.e. original file size + SSL overhead) > The original file is about 50K. What should be the overhead in > size? > > Can I do: > > s_client -debug -connect XXX.com:443 ... | grep "read from" > > read from 08089300 [080A3000] (7 bytes => 7 (0x7)) > read from 08089300 [080A3007] (72 bytes => 72 (0x48)) > read from 08089300 [080A3000] (5 bytes => 5 (0x5)) > ... > > Then, add up all the bytes for INCOMING bytes. > > And, do > > s_client -debug -connect XXX.com:443 ... | grep "write to" > > Then add up all the bytes for OUTGOING bytes. > > Many thanks. > __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: openssl performance
Ah, big difference. It is running much, much faster, and now runs pretty much even with the apache/mod_ssl server. Thanks Geoff. Chris On Monday 09 July 2001 11:17 am, you wrote: > On Mon, 9 Jul 2001, C. Gould wrote: > > I've created some server code based on openssl 0.9.6 that seems to be > > running fine. The only problem I've encountered is the noticible > > difference between the speed of my code running on a P866 and the speed > > of mod_ssl code running on another P833. Both of these machines are > > running linux-mandrake 8. > > > > Using Geoff Thorpe's swamp utility my code handles around 12 transactions > > in a second. To my surprise, the mod_ssl/openssl/apache server does > > around 18-20 transactions in a second. Is such a large difference in > > speed common? Are there steps I could have used to increase the speed > > during the configuration of openssl. > > > > Please share your experiences if you get a chance. > > I can guess what the problem is ... did you check the notes in the 'swamp' > package? I recall sticking a note there about what I think this is - > ephemeral cipher suites. I wouldn't be surprised if adding the "-cipher > RC4-MD5" command-line switch to swamp speeds things up a bit?? > > If that is the problem, the moral of the story is simple - if you simply > *must* have the server go faster than EDH cipher-suites allow, disable EDH > cipher-suites on the web server (see mod_ssl's manual). Bear in mind also > however that those numbers are all *new* SSL sessions - try using the > "-session" switch to generate test traffic that also uses resumes to see > how the system profiles as a result. > > Cheers, > Geoff > > __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
finding memory leaks
I've been tuning up my code and am now trying to locate sources of what appears to be some leaking memory. I've searched the archives and saw a bit of discussion about compiling with -DCRYPTO_MDEBUG set. When I did so there was no indication that any sort of leaks were even trying to be detected. Any suggestions as to how I can sort this situation out? Chris __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: finding memory leaks
gt; This produces tons of memory references that you'll have to sort out what > are valid and which you think are leaks. I found that I could reformat > the data with awk and do a diff between a number of sessions to see where > the memory was growing. > > Steve > > On Wed, 11 Jul 2001, C. Gould wrote: > > I've been tuning up my code and am now trying to locate sources of what > > appears to be some leaking memory. I've searched the archives and saw > > a bit of discussion about compiling with -DCRYPTO_MDEBUG set. When I did > > so there was no indication that any sort of leaks were even trying to be > > detected. Any suggestions as to how I can sort this situation out? > > > > Chris > __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Memory leaks
On Friday 27 July 2001 10:04 am, you wrote: > Hi all. > > I followed instructions in > http://marc.theaimsgroup.com/?l=openssl-users&m=99494629705968&w=2 > to find memory leaks in my application. > > The output generated by CRYPTO_mem_leaks_fp (as show below) tells me > that 899 bytes were leaked but the sum of all reported bytes is 1608. Is > that a bug or I'm reading the output incorrectely? > > CRYPTO_mem_leaks_fp output: > >32 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12D08 > 805 file=err\err.c, line=769, thread=1, number=65, address=00D136EA >16 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12920 > 5 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D126A2 >60 file=lhash\lhash.c, line=119, thread=1, number=86, > address=00D135BE >13 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D12872 >61 file=lhash\lhash.c, line=121, thread=1, number=64, > address=00D13642 >21 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D12A42 >29 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D12C12 > 2 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D125F4 >10 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D127C4 >18 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12994 >26 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12B64 > 7 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D12716 >15 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D128E6 > 0 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D124E6 >23 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D12AB6 > 4 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12668 >62 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D136B0 >12 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12838 >20 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12A08 > 1 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D125BA >28 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12BD8 > 9 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D1278A >31 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D12578 >17 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D1295A >25 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D12B2A > 6 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D126DC >14 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D128AC >33 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D12D42 >22 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12A7C >30 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12C4C > 3 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D1262E >59 file=err\err.c, line=699, thread=1, number=264, address=00D13488 >11 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D127FE >19 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D129CE >27 file=lhash\lhash.c, line=193, thread=1, number=12, > address=00D12B9E > 8 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12750 >24 file=objects\o_names.c, line=164, thread=1, number=12, > address=00D12AF0 > 899 bytes leaked in 39 chunks > > []`s Gleison > [EMAIL PROTECTED] This isn't the answer to your question but I think I can help with your leaks. Make sure you are calling EVP_cleanup and ERR_remove_state(0) before you check for leaks. These should free the algorithms and error information loaded at startup. -Chris __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Support for hardware
SSL accelerator support is built in the engine code but you need to actually
use the appropriate library calls in your code to utilize the hardware. The
following code should get you started.
ENGINE *e;
ERR_load_ENGINE_strings; // load engine error strings
e = ENGINE_by_id("cswift"); // use the cryptoswift engine
ENGINE_init(e); // initialize the engine
ENGINE_set_default(e, ENGINE_METHOD_ALL); // tell openssl to use the engine
your code here
ENGINE_free(e); // cleanup
If the engine fails to load openssl will tell you so. You can also use
"openssl" as the engine id which will use the default software support.
On Tuesday 07 August 2001 02:24 pm, Jared Crane wrote:
> I am looking into the engine version of the software and have a question
> about how it works with hardware accelerators. My concern is how will
> ssl behave if I build for an accelerator and for some reason there isn't
> one, it breaks or it is no longer available?
>
> Please send any replies to me as I have not subscribed to the list.
>
> Thanks,
> Jared
>
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing List[EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
How to use CA.sh to generate and sign certificate for weblogic CSR
Hi, I tryied to use CA.sh for several times to figure out how to get a certificate using an existent cert. requirement(CSR) generated by Weblogic domestic version(128-bit). But the attampt failed. At the beginning, I did like this: - # CA.sh -newca - # CA.sh -sign Then,I realized a newreq.pem file including certificate has to be generated before signing. But I have no idea how to enable "CA.sh -newreq" to read certificate reqiurement from weblogic.pem. It always prompts me to input completely new certificate requirement information, and generates OpenSSL's own CSR and RSA key. Please advise the proper usage to get free certificate for weblogic domestic version. Thanks in advance, Steve _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Mismatched x509 keylengths an issue?
I have a scenario where a certificate was generated using a 2048-bit key, and was signed by a CA using a 1024-bit key. The certificate is verified "OK" by openSSL, however when attempting a TLS or TTLS authentication the server fails with the following debug output: Debug output (FreeRADIUS version 2.1.8.) Error: TLS_accept:failed in SSLv3 read client certificate A Error: rlm_eap: SSL error error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error Error: SSL: SSL_read failed inside of TLS (-1), TLS session fails. The same error sequence occurs regardless of whether we use TLS or TTLS. I'm wondering if the mismatched certificate sizes could be a problem, and whether anyone else has seen this? When using a different set of certificates, but an otherwise unchanged server configuration, authentication is successful. Thanks, Diana __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
len of encrypted data
Hi... a simple question, i hope somebody know the solution: I need to use the EVP_DecryptUpdate... but for fifth argument, i need the large of encrypted.. how i do this? i'm sure that strlen not works... Thanks!!!
EVP_DecryptFinal_ex:bad decrypt
Hi i'm having problems with the function EVP_DecryptFinal_ex... i have
the next code:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define LEN_KEY 16
#define ENC_SIZE 512000
#define MSG_SIZE 512000
#define ENCRIPTA 1
#define DESENCRIPTA 0
void unbase64(unsigned char *input, char **ret, int *blen){
BIO *b64, *bmem;
char *buff,*tmp;
int length;
length = strlen(input)+1;
tmp = malloc(length*sizeof(char));
strcpy(tmp,input);
strcat(tmp,"\n\0");
buff = (char *)malloc(length);
memset(buff, 0, length);
b64 = BIO_new(BIO_f_base64());
bmem = BIO_new_mem_buf(tmp, length);
bmem = BIO_push(b64, bmem);
*blen = BIO_read(bmem, buff, length);
BIO_free_all(bmem);
strcpy(*ret,buff);
free(tmp);
free(buff);
}
void base64(const unsigned char *input, int length, char **ret){
BIO *bmem, *b64;
BUF_MEM *bptr;
char *buff;
b64 = BIO_new(BIO_f_base64());
bmem = BIO_new(BIO_s_mem());
b64 = BIO_push(b64, bmem);
BIO_write(b64, input, length);
BIO_flush(b64);
BIO_get_mem_ptr(b64, &bptr);
buff = (char *)malloc(bptr->length);
memcpy(buff, bptr->data, bptr->length-1);
buff[bptr->length-1] = 0;
BIO_free_all(b64);
strcpy(*ret,buff);
}
void rpad(const char *to_pad, char **padded, char *pad_char , int len){
int i,start;
start = strlen(to_pad);
strcpy(*padded,to_pad);
for(i = start; i <= len; i++) {
strcat(*padded,pad_char);
}
}
void lpad(const char *to_pad, char **padded, char *pad_char , int len){
int i,start;
start = strlen(to_pad);
strcpy(*padded,"");
for(i = start; i <= len; i++) {
strcat(*padded,pad_char);
}
strcat(*padded,to_pad);
}
void hextoascii(const char *hex, char **ascii){
int i;
char *tmp;
tmp = malloc(2*sizeof(char ));
strcpy(*ascii,"");
for(i=0; i < strlen(hex) ; i=i+2){
sprintf(tmp,"%c%c",*(hex+i),*(hex+i+1));
sprintf(tmp,"%c",(unsigned int)strtol(tmp,NULL,16));
strcat(*ascii,tmp);
}
free(tmp);
}
void asciitohex(const char *ascii, char **hex){
int i;
char *tmp;
tmp = malloc(2*sizeof(char ));
strcpy(*hex,"");
for(i=0; i < strlen(ascii) ; i++){
sprintf(tmp,"%02X",*(ascii+i)&255);
strcat(*hex,tmp);
}
free(tmp);
}
void tripledes(char *llave1, char *llave2, char *text, char **ret, int
action) {
EVP_CIPHER_CTX ctx;
unsigned char iv[] = "OTRACLAV";
char *key,*key1,*key2,*encrypted,*encryptedbase64,*plain;
int olen, tlen, encrypted_len,flen;
FILE *fdcypher;
key = malloc(24*sizeof(char ));
key1 = malloc(8*sizeof(char ));
key2 = malloc(8*sizeof(char ));
encryptedbase64 = malloc(ENC_SIZE*sizeof(char ));
plain = malloc(MSG_SIZE*sizeof(char ));
encrypted = malloc(ENC_SIZE*sizeof(char ));
hextoascii(llave1,&key1);
hextoascii(llave2,&key2);
strcpy(key,key1);
strcat(key,key2);
strcat(key,key1);
EVP_CIPHER_CTX_init(&ctx);
switch(action) {
case ENCRIPTA:
bzero(encrypted, ENC_SIZE);
EVP_EncryptInit_ex(&ctx, EVP_des_ede3_cbc(), NULL, key, iv);
EVP_EncryptUpdate(&ctx, encrypted, &olen, text, strlen(text));
EVP_EncryptFinal_ex(&ctx, encrypted + olen, &tlen);
EVP_CIPHER_CTX_cleanup(&ctx);
encrypted_len = olen + tlen;
base64(encrypted,encrypted_len,&encryptedbase64);
strcpy(*ret,encryptedbase64);
break;
case DESENCRIPTA:
bzero(plain, ENC_SIZE);
fdcypher = fopen(text,"r");
fseek(fdcypher, 0L, SEEK_END);
flen = ftell(fdcypher);
rewind(fdcypher);
fread(encryptedbase64,flen,1,fdcypher);
unbase64(encryptedbase64, &encrypted, &encrypted_len);
EVP_DecryptInit_ex(&ctx, EVP_des_ede3_cbc(), NULL, key, iv);
if (ERR_peek_error()) {
ERR_load_crypto_strings();
ERR_print_errors_fp(stderr);
ERR_free_strings();
}
fprintf(stderr,"%d - %d\n",strlen(encrypted),encrypted_len);
EVP_DecryptUpdate(&ctx, plain, &olen, encrypted, encrypted_len);
if (ERR_peek_error()) {
ERR_load_crypto_strings();
ERR_print_errors_fp(stderr);
ERR_free_strings();
}
EVP_DecryptFinal_ex(&ctx, plain + olen, &tlen);
if (ERR_peek_error()) {
ERR_load_crypto_strings();
ERR_print_errors_fp(stderr);
ERR_free_strings();
}
EVP_CIPHER_CTX_cleanup(&ctx);
encrypted_len = olen + tlen;
strncpy(*ret,plain,encrypted_len);
break;
}
free(key);
}
int main(int argc, char **argv ){
char *llave1,*llave2,*messge,*res;
int action;
l
3des and plain-encrypted size
Hi: I'm using the openssl and EVP_EncryptInit_ex, EVP_EncryptUpdate, EVP_EncryptFinal_ex sequence to encrypt a a short message with 3des-cbc, but i get an strange problem. I expect if the data size is 8 bytes, the encrypted data lenght is 8 bytes too, but i get 16 bytes. If the data size is 16 bytes, the encrypted data length is 24 bytes. I'm sure that the data size is 8 bytes, or 16 bytes, but i never get the expeted results, somebody know why? The command used in openssl: openssl des3 -iv 1234567812345678 -K 0123456789ABCDEFFEDCBA98765432100123456789ABCDEF -in claro.txt -out claro.bin ls -l show 8 bytes in claro.txt, and 16 bytes in claro.bin When i use the EVP_EncryptUpdate function, the strlen show 8 bytes in the text message. Thanks. -- -- José Hidalgo C. Ingeniero de Software Akzio Consultores - http://www.akzio.cl Huérfanos 669 of. 609 - Santiago Ofi:(+56)(2)6320567 - Cel:(+56)(9)88377088
Re: 3des and plain-encrypted size
Thanks!!! I solved with EVP_CIPHER_CTX_set_padding(&ctx,0), and padding the string manually On Sun, Apr 5, 2009 at 8:07 AM, Ger Hobbelt wrote: > This has to do with padding, which is at least 1 byte, and always > ensures input + padding is an integer multiple of the block size. > Hence 8 input + 1 byte minimum padding ==> 8 bytes input + 8 bytes padding. > > See what happens when you feed it, for instance, 5 bytes of input: > resulting file should be 8 bytes (des3 blocksize = 8) > > > 2009/4/3 José Hidalgo C. : > > Hi: > > > > I'm using the openssl and EVP_EncryptInit_ex, EVP_EncryptUpdate, > > EVP_EncryptFinal_ex sequence to encrypt a a short message with 3des-cbc, > but > > i get an strange problem. I expect if the data size is 8 bytes, the > > encrypted data lenght is 8 bytes too, but i get 16 bytes. If the data > size > > is 16 bytes, the encrypted data length is 24 bytes. I'm sure that the > data > > size is 8 bytes, or 16 bytes, but i never get the expeted results, > somebody > > know why? > > The command used in openssl: > > > > openssl des3 -iv 1234567812345678 -K > > 0123456789ABCDEFFEDCBA98765432100123456789ABCDEF -in claro.txt -out > > claro.bin > > > > ls -l show 8 bytes in claro.txt, and 16 bytes in claro.bin > > > > When i use the EVP_EncryptUpdate function, the strlen show 8 bytes in the > > text message. > > > > Thanks. > > > > > > -- > > -- > > José Hidalgo C. > > Ingeniero de Software > > Akzio Consultores - http://www.akzio.cl > > Huérfanos 669 of. 609 - Santiago > > Ofi:(+56)(2)6320567 - Cel:(+56)(9)88377088 > > > > > > -- > Met vriendelijke groeten / Best regards, > > Ger Hobbelt > > -- > web:http://www.hobbelt.com/ >http://www.hebbut.net/ > mail: g...@hobbelt.com > mobile: +31-6-11 120 978 > -- > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org > -- -- José Hidalgo C. Ingeniero de Software Akzio Consultores - http://www.akzio.cl Huérfanos 669 of. 609 - Santiago Ofi:(+56)(2)6320567 - Cel:(+56)(9)88377088
Help with TLS call on openssl3
HI, I am using Openssl3. while Run a TLS call, call connected successfully, but at the end of the call i got the error message: SSL3 alert write:fatal:decode error SSL error (a000126): unexpected eof while reading ERROR on SSL_read err=1 flag=0 Initiating SSL shutdown I think some issue while disconnecting the session. When i tried with openssl1 it did not throw the error. I am testing with sipp. IN wireshark i can see sipp sending TCP-FIN-ACK and openssl3 responded with TCP-PSH-ACK. Whereas in the openssl1 case it responded with a tcp message "encrypted alert" . I think some issue with closing TLS connection in openssl3. Can someone help me understand why? thanks, Saketh. 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.
need help with EVP_PKEY_derive function to generate shared key
Hi, i am trying to modify a function which earlier used openss1 to compute shared key the aruguments to the function are: rc_vchar_t *pub , rc_vchar_t *priv ; '// public and private keys. if (eay_v2bn(&dh->pub_key, pub) < 0) goto end; if (eay_v2bn(&dh->priv_key, priv) < 0) goto end; DH_compute_key(v, dh_pub, dh)) For openssl3 we are trying to use (EVP_PKEY_derive) the below code is how i implemented: rc_vchar_t *pub, rc_vchar_t *priv, // parameters to the function BIGNUM *dh_pub_key = NULL; BIGNUM *dh_priv_key = NULL; if (eay_v2bn(&dh_pub_key, pub) < 0) goto end; if (eay_v2bn(&dh_priv_key, priv) < 0) goto end; pub_key_buf = (unsigned char*) malloc( BN_num_bytes(dh_pub_key)); if (!pub_key_buf) goto end; BN_bn2nativepad(dh_pub_key, pub_key_buf, BN_num_bytes(dh_pub_key)); priv_key_buf = (unsigned char*) malloc( BN_num_bytes(dh_priv_key)); if (!priv_key_buf) goto end; BN_bn2nativepad(dh_priv_key, priv_key_buf, BN_num_bytes(dh_priv_key)); pklen = strlen((char*)priv_key_buf); peerklen = strlen((char*)pub_key_buf); const unsigned char *pub_key = ( const unsigned char *)pub_key_buf; const unsigned char *priv_key = ( const unsigned char *)priv_key_buf; pkey = d2i_PrivateKey(EVP_PKEY_RSA, &pkey, &priv_key, pklen); peerkey = d2i_PublicKey(EVP_PKEY_RSA, &peerkey, &pub_key, peerklen); ctx = EVP_PKEY_CTX_new(pkey, NULL); The problem its failing at Pkey and PeerKey creation. Does anyone have any idea how to get it working. Also can anyone suggest how to know the correct replacemant for EVP_PKEY_RSA, OR any way to know what is the type for my pub and priv keys Thanks, Saketh. 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.
Doubt regarding ssl options
Hi, what is the difference between SSL_CTX_set_min_proto_version and SSL_set_min_proto_version. How will they effect the SSL handsahke. I can see two versions numbers in the PCAP files, 1. content type is handshake , version v1.0 2. handshake type client hello, version v1.2 what is the difference and how to modify them. Thanks, Saketh. 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.
Openssl 3.0 support
Hi, Does openssl 3.0 still support TLSv 1.0 and TLSv1.1. or they are deprecated, because there were some deprecations like sha1 etc. Thanks, Saketh. 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.
error with p12 file importing
HI, I am getting this error while importing p12 file PKCS12_parse failed, error : error:0308010C:digital envelope routines::unsupported can anyone explain this? thanks, Saketh. 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.
does Openssl 3.0 has backward compatiblity.
Does openssl 3.0 supports the openssl 1.0 pkcs12 files. Is it backward compatible. For me it giving error in PKCS12_parse function. thanks, Saketh. 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.
need some help with the block size value
Hi, i am trying to get the block size of EVP_des_ede3_cbc cipher using the below function but it's not returning anything. EVP_CIPHER_get_block_size(EVP_des_ede3_cbc()) Does anyone have any idea how to. thanks, Saketh. 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.
Re: [EXTERNAL] Re: need some help with the block size value
i am using openssl 3.0 From: openssl-users on behalf of Matt Caswell Sent: Tuesday, February 15, 2022 6:45 PM To: openssl-users@openssl.org Subject: [EXTERNAL] Re: need some help with the block size value On 15/02/2022 12:13, Srinivas, Saketh (c) wrote: > Hi, > > i am trying to get the block size of EVP_des_ede3_cbc cipher using the > below function but it's not returning anything. > > EVP_CIPHER_get_block_size(EVP_des_ede3_cbc()) This code looks fine to me, and I just tested this and it returned the expected result of 8. When you say "it's not returning anything" do you mean it returns 0 or something else? What version of OpenSSL are you using? Matt > > Does anyone have any idea how to. > > thanks, > Saketh. > > 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.
error with cipher EVP_des_ede3_cbc in openssl 3.0
Hi I am trying to encrypt and decrypt using EVP_des_ede3_cbc() type. iam using openssl3.0 the functions i am using are encryption side: EVP_EncryptInit_ex -> EVP_EncryptUpdate -> EVP_EncryptFinal_ex decryption side: -- EVP_DecryptInit_ex -> EVP_DecryptUpdate -> EVP_DecryptFinal_ex but its failing in the EVP_DecryptFinal_ex. Does any have any idea on this. it's works for cipher EVP_aes_128_cbc(). Thanks, Saketh. 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.
bignum to evp key
HI, i have EvpKeyPair from GenerateEvpKeyPair(dh_p, dh_g, &pEvpKeyPair) How can I get the public key and priv key from keypair. The below function gives them as bignums but not Evp_pkey. (EVP_PKEY_get_bn_param(pEvpKeyPair, OSSL_PKEY_PARAM_PUB_KEY, &pubKey) I want pub key and priv keys as evp_pkey. Thanks, Saketh. 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.
X509_STORE_CTX object doubt
Hi, for X509_STORE_CTX object we have a function X509_STORE_CTX_set_cert to set the cert pointer (x509* cert) is there any get function for this variable. X509_STORE_CTX_get_current_cert is not for cert. Because, there is another variable current_cert. thanks, Saketh. 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.
need help with X509_STORE_CTX structure.
HI, i need to set the current_issuer field in an object of the X509_STORE_CTX structure. Can any suggest the setter function for this. current_crl_score and current_reasons also are needed to be 0 for me. Can you suggest setters for these variables. Thanks, Saketh. 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.
Help needed with X509_STORE_CTX structure
HI, i need to set the current_issuer field in an object of the X509_STORE_CTX structure. Can any suggest the setter function for this. Also, current_crl_score and current_reasons also are needed to be 0 for me. Can you suggest setters for these variables. Thanks, Saketh. 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.
Secure Remote Password (SRP)
I am trying to get information on versions and usage of the Secure Remote Password Protocol (SRP) APIs in OpenSSLv3. 1. Are SRPv3, v6, and/or v6a supported? 1. I found the following information in the OpenSSL documents on the following C API for SRP: SRP_create_verifier(), SRP_user_pwd_new(), SSL_CTX_set_srp_password() While the following documents the API : https://www.openssl.org/docs/man3.0/man3/SRP_VBASE_new.html Are there any examples of client and server programs that use these interfaces in order to register and authenticate a user? 1. The docs state that the APIs are deprecated - are new versions of the APIs planned or can we expect SRP functionality to be unavailable in future versions of OpenSSL? /R
