[FWD] OpenSSL error message
Forwarded to openssl-users for discussion. Best regards, Lutz - Forwarded message from Diogo Monteiro diogo.monte...@arquiconsult.com - From: Diogo Monteiro diogo.monte...@arquiconsult.com To: r...@openssl.org r...@openssl.org Date: Wed, 12 Jan 2011 10:21:39 -0800 Subject: OpenSSL error message Thread-Topic: OpenSSL error message Thread-Index: AcuyhY5hD3GzNEg2TC+Fc7dNv8AfsQ== Accept-Language: pt-PT, en-US acceptlanguage: pt-PT, en-US Hi all, [cid:image001.png@01CBB285.8E61A6F0] I received this error, after the installation the OpenSSL: OpenSSL information: · Win32 OpenSSL v1.0.0c SO information: · Microsoft Windows Server 2003 R2 Standard Edition Service Pack 2, 32 bits. Diogo Monteiro diogo.monte...@arquiconsult.commailto:diogo.monte...@arquiconsult.com TLM +351 96 433 0767 [cid:image002.png@01CBB285.8E61A6F0] - End forwarded message - -- Lutz Jaenicke jaeni...@openssl.org OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Trust and key store management with OpenSSL
Hi, Is there any trust store and key store API in OpenSSL? I did find a few functions of type X509_TRUST_* in the code, but it is not clear how to use them. Is the only way to manage trusted certificates, and keys is to put them in a certs directory or a flat PEM file? Thanks, Karthik, R.
Re: Trust and key store management with OpenSSL
Oops, I already asked this on the list... I forgot to check the reply. Please ignore. On Thu, Jan 13, 2011 at 3:16 PM, Karthik Ravikanti karthik.ravika...@gmail.com wrote: Hi, Is there any trust store and key store API in OpenSSL? I did find a few functions of type X509_TRUST_* in the code, but it is not clear how to use them. Is the only way to manage trusted certificates, and keys is to put them in a certs directory or a flat PEM file? Thanks, Karthik, R.
Efficient way for storing the RSA public and private keys into buffer.
Hi, I want to generate the RSA keys and store it in a buffer and send it to other modules. What is the efficient way of getting the private keys into buffer. I need to utilise very less memory for storing the RSA keys. Thanks Muneeswaran.R
Re: Trust and Key management
Thanks a LOT for the detailed reply. I was more interested in the SSL connection part. Please find my responses inline. Just to add some context, I'm trying to implement SSL sockets on the iPhone and am just using Java as a reference. On Wed, Jan 12, 2011 at 9:47 AM, Dave Thompson dthomp...@prinpay.comwrote: From: owner-openssl-us...@openssl.org On Behalf Of Karthik Ravikanti Sent: Tuesday, 11 January, 2011 00:44 Does OpenSSL provide any API for managing a trust store and a key store like Java? Not in the same way at least. OpenSSL most easily uses certs and keys (and related things) stored in files, either as DER or PEM (which is actually just labelled base64ed DER, but sometimes using different encryption where applicable i.e. privatekeys). (PEM is the format Java keytool -exportcert calls ambiguously 'rfc'.) You can read or write a file containing a cert with the X509* or PEM*X509 routines. Similarly you can read or write a file containing a privatekey. These routines can also use data from or to another store e.g. a database. You can generate (and write) keypairs (and parameters separately where applicable) and symmetric keys (useful only for lowlevel, see below, like Java). You can create a CSR for a key; issue a cert from a CSR (or IIRC directly from a key) if you act as a CA; create a selfsigned cert for a key; create CRLs if you act as a CA; etc. Unlike Java, you can have multiple certs for one key or no cert for a key if you want, although situations where this is actually useful are fairly rare. For an SSL connection, OpenSSL can directly use a PEM file containing all trusted CAcerts, or a directory containing for each CAcert a file with the filename, or usually better a symbolic link, being the hash of the CA name for lookup; there is a perl script c_rehash to (re)create hashlinks or you can build on commandline x509 (or crl). (Aside: if you need to work with existing/old OpenSSL installations, be aware the hash algorithm used here is different 0.9.8 vs 1.0.0.) The OpenSSL distro itself does not include any 'recommended' CAcerts, although I believe (some?) packagers may add that. You can easily script exporting the CAcerts in a Java distro's (or installation's) jre/lib/security/[jsse]cacerts into a file or directory for OpenSSL. I don't know any equally easy way with IE or FF, but there may be one. And of course you can add any CAcert(s) you choose to. So, the filesystem based certificate store (of PEM files) seems to be the easiest method. I looked at the PEM*() functions before, they don't seem to support augmenting an existing PEM file. if I have to add new certificates to the store is maintaining a folder of PEM files a better option? Also, if I add a certificate to an X509_STORE, will it be reflected in the file system store? I suppose I can avoid bundling any CA certs by using a native verification API when verification fails. That should guarantee that the certificate is alsways verified against the device's default list of CA certificates. I suppose there is no concept of a key store, though. What I mean is I can't just put all my private keys in a folder and call something like SSL_CTX_load_verify_locations(). I'd have to fetch the exact certificate and private key for the peer (near end). I may have to decide on a file name scheme for that. Or I probably can just use the native key store, with the overhead of converting between the native certificate and key objects to OpenSSL objects. I found a X509_TRUST_*() class of functions in the code. What do these do? Can they simplify any of this? Alternatively I understand you can write your own X509_STORE 'subclass' which gets certs (and CRLs) anyhow you wish (e.g. a database) but it's more work. For a peer's own cert (or chain) and privatekey (possibly for each of RSA, DSA, ECDSA), OpenSSL can directly read a file, or can be passed the data (DER) which you can store and obtain anyhow you wish. In PEM format 'wrong type' data is skipped, so you can put a peer's privatekey and cert together in one file, but you aren't required to. I'm planning to override just the 'verify' method in my application's SSL_CTX's X509_STORE. There I can call the native certification verification methods. Will that work? From what I've seen in the code, all the other callbacks get called only from within verify(). In particular, OpenSSL supports PKCS12 files, which Java (more exactly, the default Suncle provider) supports as a keystore type, but OpenSSL can't use them directly for SSL connections. Your app could easily use PKCS12_* to read such a file and decrypt the privatekey(s), and pass the (selected?) cert(s) and privatekey(s) to SSL_[CTX_]* . Getting CAcerts from a PKCS12 used for verification would be harder. I believe, but haven't tested, that within some limitations you could use the same PKCS12 file (for a peer) from both Java and OpenSSL, and (thus) maintain it
Re: How to disable index and serial?
On Wed, Jan 12, 2011 at 3:40 PM, Mark H. Wood mw...@iupui.edu wrote: On Tue, Jan 11, 2011 at 05:39:19PM +0100, Fredrik Strömberg wrote: Hello Patrick, Thank you for your email. I somehow managed to miss the word mandatory in the manual. I guess there´s nothing else for me to do than code a file lock. I need to run multiple openssl instances, and openssl doesn´t lock the serial and index files. That´s why I figured I´d avoid the problem by not using the serial or index file at all, and maybe supply a unique serial from the command line. That sounds like a problem with OpenSSL that should be fixed. Perhaps you could develop and share a patch that provides locking? -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. I solved the problem by making a file lock in my customized wrapper, in Python, with the fcntl module. No C code involved. My skills in C are not enough to code a patch suited for production use, unfortunately. Kind regards, Fredrik Strömberg __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re:Efficient way for storing the RSA public and private keys into buffer.
My idea is to convert the rsa into buf and compress it. int COMP_compress_block(COMP_CTX *ctx, unsigned char *out, int olen, unsigned char *in, int ilen); int COMP_expand_block(COMP_CTX *ctx, unsigned char *out, int olen, unsigned char *in, int ilen); Are these functions fit your needs? At 2011-01-13 18:09:30，Muneeswaran Raju hieswar...@gmail.com wrote: Hi, I want to generate the RSA keys and store it in a buffer and send it to other modules. What is the efficient way of getting the private keys into buffer. I need to utilise very less memory for storing the RSA keys. Thanks Muneeswaran.R
Re: Efficient way for storing the RSA public and private keys into buffer.
Hi, Your suggestion much useful. Thanks a lot. Thanks Muneeswaran.R 2011/1/13 lzyzizi lzyz...@126.com My idea is to convert the rsa into buf and compress it. int COMP_compress_block(COMP_CTX *ctx, unsigned char *out, int olen, unsigned char *in, int ilen); int COMP_expand_block(COMP_CTX *ctx, unsigned char *out, int olen, unsigned char *in, int ilen); Are these functions fit your needs? At 2011-01-13 18:09:30，Muneeswaran Raju hieswar...@gmail.com wrote: Hi, I want to generate the RSA keys and store it in a buffer and send it to other modules. What is the efficient way of getting the private keys into buffer. I need to utilise very less memory for storing the RSA keys. Thanks Muneeswaran.R
Re: Intermediate CA
On 1/12/2011 3:19 PM, Jijo wrote: Hi All, I hope this a basic question for you guys.. I'm trying to setup TLS connection between Client and Server. In the server i did following things, 1. Created a selfsigned rootCA 2. Created IntermediateCA and signed with rootCA. 3. Create a Server Certificate and signed with intermediateCA. 4. Appened the rootCA also to the server Certficate. In the Client. 1. Create a Server Certificate and signed with rootCA. 2. Stored CA as rootCA Now i made a TLS connection from Client to Server and the client returns an error:20 Unable to get Local Issuer Certficate. If the client doesn't have the intermediate certificate, how can it know the server's certificate is valid? I don't see this error if i use intermediateCA as CA in Client Am i supposed to use intermediateCA as CA in Client? You have to get the IC to the client somehow. The usual method is to have the server send it. Does the server software provide a way to supply a certificate chain? DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Way to generate RSA key pair by taking as random input string
Hi, Is there any Way to generate RSA key pair by taking as random input string . Normally I understand that prime numbers P and Q will be generated randomly inside the function RSA_generate_key . If there is any way to generate RSA key pair from random input string, please let know. Thanks Muneeswaran.R
Re: [openssl-users] Re: How to disable index and serial?
Ah. I did not understand that referenced by browser vendors meant we were talking about inclusion in their canned trust stores. Thanks, both of you. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpbxjvrsNucj.pgp Description: PGP signature
Re: Intermediate CA
Thanks for the response.. You have to get the IC to the client somehow. The usual method is to have the server send it. Does the server software provide a way to supply a certificate chain? What do you mean by server sending it? is it on TLS negotiation? What do you mean by certificate chain? is it rootCA and IntermediateCA combined in a pem file?. Thanks Jijo On Thu, Jan 13, 2011 at 9:39 AM, David Schwartz dav...@webmaster.comwrote: On 1/12/2011 3:19 PM, Jijo wrote: Hi All, I hope this a basic question for you guys.. I'm trying to setup TLS connection between Client and Server. In the server i did following things, 1. Created a selfsigned rootCA 2. Created IntermediateCA and signed with rootCA. 3. Create a Server Certificate and signed with intermediateCA. 4. Appened the rootCA also to the server Certficate. In the Client. 1. Create a Server Certificate and signed with rootCA. 2. Stored CA as rootCA Now i made a TLS connection from Client to Server and the client returns an error:20 Unable to get Local Issuer Certficate. If the client doesn't have the intermediate certificate, how can it know the server's certificate is valid? I don't see this error if i use intermediateCA as CA in Client Am i supposed to use intermediateCA as CA in Client? You have to get the IC to the client somehow. The usual method is to have the server send it. Does the server software provide a way to supply a certificate chain? DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Intermediate CA
Hi Jijo, I believe interesting information can be found here : http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html Regards Le 13/01/2011 17:16, Jijo a écrit : Thanks for the response.. You have to get the IC to the client somehow. The usual method is to have the server send it. Does the server software provide a way to supply a certificate chain? What do you mean by server sending it? is it on TLS negotiation? What do you mean by certificate chain? is it rootCA and IntermediateCA combined in a pem file?. Thanks Jijo __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Trust and Key management
From: owner-openssl-us...@openssl.org On Behalf Of Karthik Ravikanti Sent: Thursday, 13 January, 2011 05:12 Thanks a LOT for the detailed reply. I was more interested in the SSL connection part. Please find my responses inline. Just to add some context, I'm trying to implement SSL sockets on the iPhone and am just using Java as a reference. On Wed, Jan 12, 2011 at 9:47 AM, Dave Thompson dthomp...@prinpay.com wrote: For an SSL connection, OpenSSL can directly use a PEM file containing all trusted CAcerts, or a directory containing for each CAcert a file with the filename, or usually better a symbolic link, being the hash of the CA name for lookup; ... So, the filesystem based certificate store (of PEM files) seems to be the easiest method. I looked at the PEM*() functions before, they don't seem to support augmenting an existing PEM file. if I have to add new certificates to the store is maintaining a folder of PEM files a better option? The PEM* routines can use a C filepointer or a BIO and C fopen() can append to an existing file on output. Replacing or deleting an entry would be harder. Separate file (in dir) is simple, and easy to replace or delete, but unless you use hash *names* make sure hash links are created/updated as necessary. Also, if I add a certificate to an X509_STORE, will it be reflected in the file system store? Not automatically. I suppose I can avoid bundling any CA certs by using a native verification API when verification fails. That should guarantee that the certificate is alsways verified against the device's default list of CA certificates. Should work, although I haven't tried it. I suppose there is no concept of a key store, though. What I mean is I can't just put all my private keys in a folder and call something like SSL_CTX_load_verify_locations(). I'd have to fetch the exact certificate and private key for the peer (near end). I may have to decide on a file name scheme for that. Yes. If there is a choice, i.e. you have multiple key/certs for your device, often called 'identities', your code must give the right one for a session to SSL_[CTX_]use* . OpenSSL won't pick the right one out of a set -- even if the server specifies a desired CA (or list) which would be sufficient to select e.g. 'me-retail' vs 'me-internal'. (Except for different PK *algorithms*; you can set one privkey/cert for RSA and one for DSA and one for ECDSA, and OpenSSL will use the one for the ciphersuite negotiated. But doing e.g. RSA for one identity and DSA for a different identity will generally produce different security results depending on server features you can't control and most users don't understand, causing errors and confusion.) Using filename(s) for that is easy, although I can think of other methods like an index file. Of course this is assuming you use/need (SSL) client auth. Many Internet applications don't. Or I probably can just use the native key store, with the overhead of converting between the native certificate and key objects to OpenSSL objects. Should work, if the native keystore lets you get the actual privkey out as PKCS#1. (And the cert as X.509, but no one has a good reason to restrict certs or use other than X.509.) I'd be unpleasantly surprised if the overhead of converting a key is significant compared to the overhead of an SSL connection -- but I have had some unpleasant surprises in my life. For certs I'd be surprised to see anyone use something besides X.509 -- nothing else has significant public acceptance. I found a X509_TRUST_*() class of functions in the code. What do these do? Can they simplify any of this? I don't know exactly; I don't use them. I think they add some finer trust settings to an X.509 cert, kind of like keyUsage or extendedKeyUsage but not set/confirmed/signed by the CA. Firefox does a similar thing: you can change some (simple) options for a cert in its truststore without changing the cert. Alternatively I understand you can write your own X509_STORE 'subclass' which gets certs (and CRLs) anyhow you wish (e.g. a database) but it's more work. ... I'm planning to override just the 'verify' method in my application's SSL_CTX's X509_STORE. There I can call the native certification verification methods. Will that work? From what I've seen in the code, all the other callbacks get called only from within verify(). When I've needed to trace though cert verify logic (with default STORE and LOOKUPs, using a pre-read file or a hashlinked directory) it reminded me forcefully of the Gordian knot. Just replacing one method may work, but I'm not at all certain. On more thought, to just use your own store it's probably enough to change the X509_LOOKUP(s) in the X509_STORE, not the entire STORE.
Re: Trust and Key management
On Fri, Jan 14, 2011 at 8:03 AM, Dave Thompson dthomp...@prinpay.comwrote: From: owner-openssl-us...@openssl.org On Behalf Of Karthik Ravikanti Sent: Thursday, 13 January, 2011 05:12 Thanks a LOT for the detailed reply. I was more interested in the SSL connection part. Please find my responses inline. Just to add some context, I'm trying to implement SSL sockets on the iPhone and am just using Java as a reference. On Wed, Jan 12, 2011 at 9:47 AM, Dave Thompson dthomp...@prinpay.com wrote: For an SSL connection, OpenSSL can directly use a PEM file containing all trusted CAcerts, or a directory containing for each CAcert a file with the filename, or usually better a symbolic link, being the hash of the CA name for lookup; ... So, the filesystem based certificate store (of PEM files) seems to be the easiest method. I looked at the PEM*() functions before, they don't seem to support augmenting an existing PEM file. if I have to add new certificates to the store is maintaining a folder of PEM files a better option? The PEM* routines can use a C filepointer or a BIO and C fopen() can append to an existing file on output. Replacing or deleting an entry would be harder. Separate file (in dir) is simple, and easy to replace or delete, but unless you use hash *names* make sure hash links are created/updated as necessary. Also, if I add a certificate to an X509_STORE, will it be reflected in the file system store? Not automatically. I suppose I can avoid bundling any CA certs by using a native verification API when verification fails. That should guarantee that the certificate is alsways verified against the device's default list of CA certificates. Should work, although I haven't tried it. I suppose there is no concept of a key store, though. What I mean is I can't just put all my private keys in a folder and call something like SSL_CTX_load_verify_locations(). I'd have to fetch the exact certificate and private key for the peer (near end). I may have to decide on a file name scheme for that. Yes. If there is a choice, i.e. you have multiple key/certs for your device, often called 'identities', your code must give the right one for a session to SSL_[CTX_]use* . OpenSSL won't pick the right one out of a set -- even if the server specifies a desired CA (or list) which would be sufficient to select e.g. 'me-retail' vs 'me-internal'. (Except for different PK *algorithms*; you can set one privkey/cert for RSA and one for DSA and one for ECDSA, and OpenSSL will use the one for the ciphersuite negotiated. But doing e.g. RSA for one identity and DSA for a different identity will generally produce different security results depending on server features you can't control and most users don't understand, causing errors and confusion.) Using filename(s) for that is easy, although I can think of other methods like an index file. Of course this is assuming you use/need (SSL) client auth. Many Internet applications don't. Or I probably can just use the native key store, with the overhead of converting between the native certificate and key objects to OpenSSL objects. Should work, if the native keystore lets you get the actual privkey out as PKCS#1. (And the cert as X.509, but no one has a good reason to restrict certs or use other than X.509.) I'd be unpleasantly surprised if the overhead of converting a key is significant compared to the overhead of an SSL connection -- but I have had some unpleasant surprises in my life. For certs I'd be surprised to see anyone use something besides X.509 -- nothing else has significant public acceptance. I found a X509_TRUST_*() class of functions in the code. What do these do? Can they simplify any of this? I don't know exactly; I don't use them. I think they add some finer trust settings to an X.509 cert, kind of like keyUsage or extendedKeyUsage but not set/confirmed/signed by the CA. Firefox does a similar thing: you can change some (simple) options for a cert in its truststore without changing the cert. Alternatively I understand you can write your own X509_STORE 'subclass' which gets certs (and CRLs) anyhow you wish (e.g. a database) but it's more work. ... I'm planning to override just the 'verify' method in my application's SSL_CTX's X509_STORE. There I can call the native certification verification methods. Will that work? From what I've seen in the code, all the other callbacks get called only from within verify(). When I've needed to trace though cert verify logic (with default STORE and LOOKUPs, using a pre-read file or a hashlinked directory) it reminded me forcefully of the Gordian knot. Just replacing one method may work, but I'm not at all certain. On more thought, to just
Re: Trust and Key management
On Fri, Jan 14, 2011 at 8:03 AM, Dave Thompson dthomp...@prinpay.comwrote: From: owner-openssl-us...@openssl.org On Behalf Of Karthik Ravikanti Sent: Thursday, 13 January, 2011 05:12 Thanks a LOT for the detailed reply. I was more interested in the SSL connection part. Please find my responses inline. Just to add some context, I'm trying to implement SSL sockets on the iPhone and am just using Java as a reference. On Wed, Jan 12, 2011 at 9:47 AM, Dave Thompson dthomp...@prinpay.com wrote: For an SSL connection, OpenSSL can directly use a PEM file containing all trusted CAcerts, or a directory containing for each CAcert a file with the filename, or usually better a symbolic link, being the hash of the CA name for lookup; ... So, the filesystem based certificate store (of PEM files) seems to be the easiest method. I looked at the PEM*() functions before, they don't seem to support augmenting an existing PEM file. if I have to add new certificates to the store is maintaining a folder of PEM files a better option? The PEM* routines can use a C filepointer or a BIO and C fopen() can append to an existing file on output. Replacing or deleting an entry would be harder. Separate file (in dir) is simple, and easy to replace or delete, but unless you use hash *names* make sure hash links are created/updated as necessary. Also, if I add a certificate to an X509_STORE, will it be reflected in the file system store? Not automatically. So, I have to add the cert to the X509_STORE object first (only the first time, probably) and then also write to my custom certs directory? I suppose I can avoid bundling any CA certs by using a native verification API when verification fails. That should guarantee that the certificate is alsways verified against the device's default list of CA certificates. Should work, although I haven't tried it. I suppose there is no concept of a key store, though. What I mean is I can't just put all my private keys in a folder and call something like SSL_CTX_load_verify_locations(). I'd have to fetch the exact certificate and private key for the peer (near end). I may have to decide on a file name scheme for that. Yes. If there is a choice, i.e. you have multiple key/certs for your device, often called 'identities', your code must give the right one for a session to SSL_[CTX_]use* . OpenSSL won't pick the right one out of a set -- even if the server specifies a desired CA (or list) which would be sufficient to select e.g. 'me-retail' vs 'me-internal'. (Except for different PK *algorithms*; you can set one privkey/cert for RSA and one for DSA and one for ECDSA, and OpenSSL will use the one for the ciphersuite negotiated. But doing e.g. RSA for one identity and DSA for a different identity will generally produce different security results depending on server features you can't control and most users don't understand, causing errors and confusion.) Using filename(s) for that is easy, although I can think of other methods like an index file. Of course this is assuming you use/need (SSL) client auth. Many Internet applications don't. Or I probably can just use the native key store, with the overhead of converting between the native certificate and key objects to OpenSSL objects. Should work, if the native keystore lets you get the actual privkey out as PKCS#1. (And the cert as X.509, but no one has a good reason to restrict certs or use other than X.509.) I'd be unpleasantly surprised if the overhead of converting a key is significant compared to the overhead of an SSL connection -- but I have had some unpleasant surprises in my life. For certs I'd be surprised to see anyone use something besides X.509 -- nothing else has significant public acceptance. I found a X509_TRUST_*() class of functions in the code. What do these do? Can they simplify any of this? I don't know exactly; I don't use them. I think they add some finer trust settings to an X.509 cert, kind of like keyUsage or extendedKeyUsage but not set/confirmed/signed by the CA. Firefox does a similar thing: you can change some (simple) options for a cert in its truststore without changing the cert. Alternatively I understand you can write your own X509_STORE 'subclass' which gets certs (and CRLs) anyhow you wish (e.g. a database) but it's more work. ... I'm planning to override just the 'verify' method in my application's SSL_CTX's X509_STORE. There I can call the native certification verification methods. Will that work? From what I've seen in the code, all the other callbacks get called only from within verify(). When I've needed to trace though cert verify logic (with default STORE and LOOKUPs, using a pre-read file or a hashlinked
