Why doees an SSL client cert have a private/public key embedded?
I have successfully generated SSL client certificates for my Apache web site users, and we have successfully tested them using it to access my restricted areas on my web site. One thing I'm not sure of is why there is a private/public key pair in the client certs. Hopefully it's not the same private key used to generate the CSR, or is it? In any event, why is it needed? All I am using the certs for is to allow access to my site which is done by (as I understand it) Apache checking that (1) the client cert hasn't been revoked and (2) it has been signed by me as the CA. BTW, I currently have not put any restrictions in the client certs. Would that make a difference? I will test that while I await any responses. Thanks for any help. Best regards, -Tom __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why doees an SSL client cert have a private/public key embedded?
Am 21.10.12 19:25, schrieb Tom Browder: I have successfully generated SSL client certificates for my Apache web site users, and we have successfully tested them using it to access my restricted areas on my web site. One thing I'm not sure of is why there is a private/public key pair in the client certs. You must be misinterpreting what you are seeing. The certificate data structure isn't capable of storing private keys, so if you see the private key embedded somewhere, it's not a client cert it is embedded in. Hopefully it's not the same private key used to generate the CSR, or is it? The private key to generate a CSR for a certificate is the CA's private key. So if you have a separate CA, then no, it's not the same key. If you are using self-signed certificates, revoking them is not possible. In any event, why is it needed? All I am using the certs for is to allow access to my site which is done by (as I understand it) Apache checking that (1) the client cert hasn't been revoked and (2) it has been signed by me as the CA. The web browser also needs access to the private key, as a proof that it really represents the identity that is mentioned in the cert. Otherwise, anybody could copy the certificate from the wire, or from some directory service (it's really public). The server shouldn't have the private key at all - the private key should never leave the machine on which the browser is running. Regards, Martin __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Why doees an SSL client cert have a private/public key embedded?
On Sun, Oct 21, 2012 at 2:34 PM, Martin v. Löwis mar...@v.loewis.de wrote: Am 21.10.12 19:25, schrieb Tom Browder: I have successfully generated SSL client certificates for my Apache web site users, and we have successfully tested them using it to access my restricted areas on my web site. One thing I'm not sure of is why there is a private/public key pair in the client certs. You must be misinterpreting what you are seeing. The certificate data structure isn't capable of storing private keys, so if you see the private key embedded somewhere, it's not a client cert it is embedded in. Martin, you are correct--I got mixed up over some other thing and thought I saw info on a private key in a client certificate. However, I just checked the cert. again in two browsers (Firefox and Chrome), as well as with openssl, and see no reference to a private key. Sorry for the false alarm. Thanks, Martin. Best regards, -Tom __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re:RE: problem with cross compile OpenSSL
Dave,thanks very much for you reply. The problem is still existing. From:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ??? Sent: Friday, 19 October, 2012 02:44 To:openssl-users@openssl.org Subject: problem with cross compile OpenSSL Hi， I am glad to talk with you.Now I have a problem when I using OpenSSL. I want to use openssl on my ARM platform,so I need to cross compile it.I download the openssl-1.0.1c from the openssl.org.I used arm-linux-gcc(libc2.2.5) to comlile it successfully,getting libssl.a ,libcrypto.a and openssl.But when I run openssl on my ARM with the command ./openssl s_client -connect smtp.gmail.com:465 -state,it got error.the messages is CONNECTED(0003) SSL_connect:before/connect initialization SSL_connect:error in SSLv2/v3 write client hello A write:errno=0 --- error on *write*, and with errno=0? That's very weird. Write on a TCP socket immediately after connecting should never fail. Leave openssl out of the picture for a moment. If you (cross)compile a program which just does a plain TCP socket connection, does it work? It runs well when I just does a plain TCP socket connection. (Since you want access to gmail, you might try connecting to www.google.com 80, sending the simplest possible HTTP request: GET / HTTP/1.0\r\n\r\n and seeing if you get any reply data (probably doesn't matter what, although it should be an HTML page), or some socket/OS error. I used openssl(I cross compileed) to run any command s_client -connect ,It gets the same error. CONNECTED(0003) SSL_connect:before/connect initialization SSL_connect:error in SSLv2/v3 write client hello A write:errno=0 the similar problems ,I made a test program with libssl.a ,libcrypto.a which I cross compiled . SSL_connect function return -1,I use SSL_get_error ,i got the errno 5(SSL_ERROR_SYSCALL),and ERR_get_error to check,it return 0,I find the documents which says If ret == 0, an EOF was observed that violates the protocol. I don't know what's the meaning and how to solve it. Note 'ret == 0' in SSL_get_error manpage means the return from SSL_connect (passed to SSL_get_error) not the return from ERR_get_error. You say SSL_connect returned -1, so read the next sentence to cover that case, and as it says on Unix look at errno. thanks for your reminding,I just want to check SSL_connect error .SSL_ERROR_SYSCALL which and where can cause this error.
Re: X509 V1 intermediate CA vs end-entity
You can find out if the V1 cert verifies directly with any of the certificates in the trust store or its own public key. There's pretty much nothing else you can do with it, other than try to link it to a Distinguished Name that may or may not be useful. Also, (EXFLAG_V1|EXFLAG_SS) doesn't tell you if it's intended to be a CA certificate. X.509 actually disclaims the idea of self-signed certificates altogether (except as containers for trust anchors). -Kyle H On Tue, Sep 25, 2012 at 10:33 PM, sanjaya joshi joshi.sanj...@gmail.com wrote: Hi steve, Thanks. Got it. That means we can't differentiate between CA and end-entity in case of V1 certificate. We can only find out if the V1 cert is a self-signed certificate or not. Correct ? Regards, Sanjaya On Wed, Sep 26, 2012 at 2:36 AM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Sep 25, 2012, sanjaya joshi wrote: We can conclude an X509 V1 certificate to be a root ca using (EXFLAG_V1|EXFLAG_SS). Similarly, is there a way to know whether an X509 V1 certificate is an intermediate CA or end-entity certificate ? You can't: there is nothing in a V1 certificate to mark it as a CA. You can't actually be sure it is a root CA using the test you mentioned above: it could be a self signed end entity certificate. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Bug report
Version of OpenSSL being effected OpenSSL 1.0.1c Version of the operating system being used Windows XP Seems there is a limitation to the size of text that can be encrypted through Openssl command prompt via Echo ex: echo 'test string 1' | openssl enc -aes-256-cbc -a -salt -pass pass:mypassword When we are trying to encrypt large text using the above command it fails, where as if we keep the same text in a plain text file and use the following command openssl aes-256-cbc -in c:\attack-plan.txt -out c:\encryptedmessage.txt -pass pass:mypassword Sure you're not facing a shell limitation? How much large is your large text? What kind of error/anomaly do you see? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: win32 exe linked with -lssl -lcrypt
On 10/14/2012 11:53 PM, ml wrote: hello sir and doctor i am a little question concerning the presence of libssl.dll libcrypt.dll into the win32 standard system or OS into linux this lib are very standard its the same when are the poor win32 OS is ready If it is a question, the answer is no. You can find OpenSSL DLLs precompiled for Windows on the Internet, though, it is much simpler to download it than compile it yourself, unless you need to be sure the code hasn't been tampered! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Why doees an SSL client cert have a private/public key embedded?
From: owner-openssl-us...@openssl.org On Behalf Of Martin v. Löwis Sent: Sunday, 21 October, 2012 15:35 Am 21.10.12 19:25, schrieb Tom Browder: I have successfully generated SSL client certificates for my Apache web site users, snip One thing I'm not sure of is why there is a private/public key pair in the client certs. rescinded elsethread You must be misinterpreting what you are seeing. The certificate data structure isn't capable of storing private keys, so if you see the private key embedded somewhere, it's not a client cert it is embedded in. Not quite. X509v1 and v2 can't contain a privatekey. v3, and PKCS#? CSR, support extensions that allow you to add any data if you get all relevant parties to implement or ignore it. It would be appallingly stupid to put privatekey in an extension, and contravene the whole purpose of having certs, but it would be possible. openssl does not define or have code to support any such extension, but you could do it in custom code or with the raw DER support. Hopefully it's not the same private key used to generate the CSR, or is it? The private key to generate a CSR for a certificate is the CA's private key. So if you have a separate CA, then no, it's not the same key. If you are using self-signed certificates, revoking them is not possible. ITYM the CSR is signed by the *entity* privatekey; the *cert* is signed by the CA privatekey. To add the other half to what you say, for selfsigned these entity and CA keys are the same (and you don't really need a CSR), otherwise they are different. In any event, why is it needed? All I am using the certs for is to allow access to my site which is done by (as I understand it) Apache checking that (1) the client cert hasn't been revoked and (2) it has been signed by me as the CA. The web browser also needs access to the private key, as a proof that it really represents the identity that is mentioned in the cert. Otherwise, anybody could copy the certificate from the wire, or from some directory service (it's really public). The server shouldn't have the private key at all - the private key should never leave the machine on which the browser is running. Yes/maybe. If you generate the keypair and CSR on the client and send the CSR to the CA and get back the cert, the privatekey can and should be only on the client -- except you might want an encrypted or otherwise protected backup, so when the PC dies you don't have to start over. If you don't have (convenient) tools and sufficiently competent users on the clients -- which does happen in the real world -- another method is to generate the keypair and CSR for each client (separately) on a trusted central party, get a cert, and provide each client the (unique) privatekey and matching cert to use. Typically -- especially for web browsers -- this is in the form of a PKCS#8 aka PFX. A private CA like the OP implies is trusted anyway and has the tools to be such a key provider. To deserve this trust, it must either destroy or protect these privatekeys after issuance, and certainly should never give them to anyone else, except someone authorized, such as the police with a subpoena -- at least if your police are reasonably honest, and if not you have bigger problems than SSL. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
