RE: client authentication status
Thanks for the explanation. I figured I was headed down a dead end. This will at least help me figure out how to handle things appropriately. Zeke Evans
Re: client authentication status
On 01/09/2021 16:36, Zeke Evans wrote:
Is there any way to check the status of client authentication sent in a
TLS 1.3 handshake after SSL_connect returns? With TLS 1.2 SSL_connect
seems to always capture the status and return an error code if it failed
but not TLS 1.3. I haven’t been able to find a good way to do this
after SSL_connect returns. I have to handle blocking and non-blocking
sockets so calling SSL_read or SSL_peek isn’t an option since those
could block. If client authentication happened to fail then calling
those methods would work because they will return an error but if it
didn’t fail then they could block.
At a protocol level the handshake looks like this:
Client Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* >
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
< [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} >
[Application Data] <---> [Application Data]
The handshake has completed from the perspective of one of the endpoints
once it has both sent and received a "Finished" message.
From the above you can see that the client receives the server's
"Finished" message before it sends its "Certificate"/"CertificateVerify"
and "Finished" messages back to the server. At this point "SSL_connect"
returns and the client is ready to start receiving application data.
From the server's perspective it is still handshaking when it receives
the client's certificate (because it didn't receive the client's
"Finished" message yet). So the server when send an alert at this point
if the certificate is not acceptable and SSL_accept() will return with a
failure.
The client does not know what it will receive back from the server. It
could either be application data (in the case of an accepted
certificate) or an alert (in the case of a reject certificate). The only
way it can find out is to attempt to read data from the connection and
see what it gets back. The API to do this is SSL_read()/SSL_peek().
So, to answer your question, there is no way to check the status of
client authentication without calling SSL_read()/SSL_peek(). It
necessarily requires an attempt to read data from the socket in order to
find that status out due to the way the protocol is designed.
On 01/09/2021 16:51, Benjamin Kaduk via openssl-users wrote:
> Note that the server is allowed to ignore a client cert that it
doesn't like, proceeding with the connection as if the client was
unauthenticated. If you need a specific signal that the server believes
the client successfully authenticated, that has to be at the application
layer.
This is true, but ultimately the client still needs to attempt to read
data from the socket to figure out what the server did.
> Did you try a zero-length SSL_read()? My recollection is that that
gets far enough into the library to see if there are pending alert
messages to process.
Again, there will only be alerts to process (related to a client
certificate failure) if the client has attempted to read application data.
Matt
Re: client authentication status
On Wed, Sep 01, 2021 at 03:36:36PM +, Zeke Evans wrote: > Hi, > > Is there any way to check the status of client authentication sent in a TLS > 1.3 handshake after SSL_connect returns? With TLS 1.2 SSL_connect seems to > always capture the status and return an error code if it failed but not TLS > 1.3. I haven't been able to find a good way to do this after SSL_connect > returns. I have to handle blocking and non-blocking sockets so calling > SSL_read or SSL_peek isn't an option since those could block. If client > authentication happened to fail then calling those methods would work because > they will return an error but if it didn't fail then they could block. Note that the server is allowed to ignore a client cert that it doesn't like, proceeding with the connection as if the client was unauthenticated. If you need a specific signal that the server believes the client successfully authenticated, that has to be at the application layer. Did you try a zero-length SSL_read()? My recollection is that that gets far enough into the library to see if there are pending alert messages to process. -Ben
client authentication status
Hi, Is there any way to check the status of client authentication sent in a TLS 1.3 handshake after SSL_connect returns? With TLS 1.2 SSL_connect seems to always capture the status and return an error code if it failed but not TLS 1.3. I haven't been able to find a good way to do this after SSL_connect returns. I have to handle blocking and non-blocking sockets so calling SSL_read or SSL_peek isn't an option since those could block. If client authentication happened to fail then calling those methods would work because they will return an error but if it didn't fail then they could block. Thanks, Zeke Evans
Re: TLS with Client Authentication using private key from Windows store
Hi Ferenc, On 23/11/20 13:03, Ferenc Gerlits via openssl-users wrote: Hi, I am trying to use openssl to implement a client-side TLS connection with Client Authentication on Windows, using a non-exportable private key stored in the Windows Certificate Store. Currently, our code can use a private key stored in a local file, and if the key in the Windows store was exportable, I could export it and use it in the existing code. But the key is non-exportable, which is a problem. Does anyone know how to do this? So far, I have found suggestions to use the CAPI engine (eg. https://groups.google.com/g/mailing.openssl.users/c/_rdJLc7emAY?pli=1), but no examples of how to do that, and also some tickets (eg. https://github.com/openssl/openssl/issues/12859) which say that the CAPI engine does not work with TLS >= 1.2 on openssl 1.1.1, so that doesn't look like a good solution. OpenVPN 2.4+ can use the Windows Certificate Store to encrypt and sign traffic using CNG (Crypto Next Gen, I believe). I'd suggest you download the source code and examine the file cryptoapi.c for details. HTH, JJK
TLS with Client Authentication using private key from Windows store
Hi, I am trying to use openssl to implement a client-side TLS connection with Client Authentication on Windows, using a non-exportable private key stored in the Windows Certificate Store. Currently, our code can use a private key stored in a local file, and if the key in the Windows store was exportable, I could export it and use it in the existing code. But the key is non-exportable, which is a problem. Does anyone know how to do this? So far, I have found suggestions to use the CAPI engine (eg. https://groups.google.com/g/mailing.openssl.users/c/_rdJLc7emAY?pli=1), but no examples of how to do that, and also some tickets (eg. https://github.com/openssl/openssl/issues/12859) which say that the CAPI engine does not work with TLS >= 1.2 on openssl 1.1.1, so that doesn't look like a good solution. Any help would be appreciated! Thank you, Ferenc
[openssl-users] Key Usage and Extended Key Usage certificate extension values should be required in client authentication
Hi all, Anyone knows in client authentication, what are the Key Usage and Extended Key Usage purposes we should validate? As per the specification in [1]: - "Extended Key Usage" is not necessary and which is configured in addition to or in place of the basic purposes indicated in the key usage extension. - "clientAuth" which can be configure as "Extended Key Usage", and Key usage bits that may be consistent for that is "digitalSignature" and/or "keyAgreement" But when validating, what are the key usage purposes that should be allowed and disallowed for client authentication? [1] https://tools.ietf.org/html/rfc5280#section-4.2.1.12 Thanks and Regards -- *Indunil Rathnayake * *Faculty of Information Technology* *University of Moratuwa.* Email : *indunil@gmail.com * | Skype: indu.upeksha | Mobile : (+94)713695179 | Twitter @indunilUR | LinkedIn: http://lk.linkedin.com/in/indunil <http://www.google.com/url?q=http%3A%2F%2Flk.linkedin.com%2Fin%2Findunil&sa=D&sntz=1&usg=AFQjCNEmFm8EqJj46HTiFXEXdDLn3kJ79A> | Facebook : https://www.facebook.com/indunilrathnayake80 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Client authentication certificate verification
I understand that the trusted store must include Intermediate CA 1 or remove Intermediate CA 2 and just have the Root CA in it. I was trying things out to understand how client authentication works. Regards, Sudarshan On Tue, Aug 22, 2017 at 10:37 AM, Sudarshan Raghavan < sudarshan.t.ragha...@gmail.com> wrote: > This is the CA - Leaf hierarchy I am testing with > > Root CA > Intermediate CA 1 > Intermediate CA 2 > Leaf > > Trusted certificates configured: Root CA and Intermediate CA 2 > > Client authenticates itself with this chain: Leaf > Intermediate CA 2 > > Intermediate CA 1 > > I am using openssl 1.1.0f. This client authentication attempt is flagged > as failed by OpenSSL. When I enable the X509_V_FLAG_PARTIAL_CHAIN flag, it > passes. I was trying to understand why the partial chain flag is needed > when the verification chain from Leaf to Root CA can be constructed using > both the chain sent by the client and the certificates configured in > trusted store. I looked at the code in build_chain function inside > crypto/x509/x509_vfy.c. This is what I understand. If the issuer of Leaf > certificate (Intermediate CA 2) is found in trusted store, the code will no > longer look in the untrusted chain sent by the client. The code expects the > chain to Root CA can be constructed from the trusted store itself. Given > Intermediate CA 1 is not in the trusted store, it fails to construct the > verification chain to Root CA and flags a failure. Did I understand this > right? I assume in this scenario, enabling the partial chain flag is the > way to go. > > Regards, > Sudarshan > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Client authentication certificate verification
This is the CA - Leaf hierarchy I am testing with Root CA > Intermediate CA 1 > Intermediate CA 2 > Leaf Trusted certificates configured: Root CA and Intermediate CA 2 Client authenticates itself with this chain: Leaf > Intermediate CA 2 > Intermediate CA 1 I am using openssl 1.1.0f. This client authentication attempt is flagged as failed by OpenSSL. When I enable the X509_V_FLAG_PARTIAL_CHAIN flag, it passes. I was trying to understand why the partial chain flag is needed when the verification chain from Leaf to Root CA can be constructed using both the chain sent by the client and the certificates configured in trusted store. I looked at the code in build_chain function inside crypto/x509/x509_vfy.c. This is what I understand. If the issuer of Leaf certificate (Intermediate CA 2) is found in trusted store, the code will no longer look in the untrusted chain sent by the client. The code expects the chain to Root CA can be constructed from the trusted store itself. Given Intermediate CA 1 is not in the trusted store, it fails to construct the verification chain to Root CA and flags a failure. Did I understand this right? I assume in this scenario, enabling the partial chain flag is the way to go. Regards, Sudarshan -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Openssl-1.0.1e RSA 8k is getting fail for client authentication while doing Normal Handshake
Commands Used: x86_server: openssl s_server -cert sercert8192.pem -key serverkey8192 -Verify CAcert.pem x86_client: openssl s_client -cert clientcert8192.pem -key clientkey8192 -connect : -cipher AES128-SHA - Error log: x86( Server): verify error:unable to verify the first certificate x86 (Client): 140631662409384:error:14094417:SSL routines:SSL3_READ_BYTES:sslv3 alert illegal parameter:s3_pkt.c:1256:SSL alert number 47 140631662409384:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: Do we need to enable any flag to access 8k support? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Similar issuer dn mod_ssl client authentication issue
Dear openssl group, could you solve this issue regarding mod_ssl? Michele Masè On Thu, May 23, 2013 at 10:11 AM, Michele Mase' wrote: > Okay, openssl works, but mod_ssl doesn't. > Is this a real problem? > Instead try hacking mod_ssl code ... > Could I ask for a bug/improvement so that mod_ssl could finally work? > > Michele MAsè > > > On Thu, May 23, 2013 at 1:22 AM, Dave Thompson > wrote: >> >> >From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' >> >Sent: Tuesday, 21 May, 2013 04:16 >> >> I was wrong! >> >> >"Does it work with client=Firefox using client certs under both CAs? >> >I would expect at least one to fail. Note that s_server -verify >> >doesn't *require* client cert, it only *allows* it; how did you >> >check Firefox is actually using your client cert(s)?" >> >> >I've tested it with both smart card >> >> I went back and set up a (modified) test and ... I was wrong! >> The lookup as such does use the canonical DN and returns only one, >> sometimes the wrong one. But I didn't realize X509_STORE_get1_issuer >> hiddenly caches *all* the matches and tries them, and (given you >> have AKI) *does* select the correct one. So actually your earlier >> tries should have worked, or at least not failed for this reason. >> >> >"The certificates you attached are CA roots and have no AKI. >> >pardon, my mistake, I forgot to send the clients certs :( >> >> >As attachment, there are the client certificates I used. >> >> And those do indeed have AKI (correctly matching the roots). >> >> >"I don't know what "exclusive mode" means here." >> >virtualhost1 has the ca's bundle made with all certificates + ca1 (for >> smart card1) >> >virtualhost2 has the ca's bundle made with all certificates + ca2, (for >> smart card2); >> >the or (exclusive) means you can try virtualhost1 with smart card1 >> >or virtualhost2 with scard2 >> >> Okay. >> >> >RFC3280 - is it correct? >> >> >> Actually, 3280 has been superseded by 5280, which has more >> complicated rules to handle internationalization using >> Unicode and IDN, but for this simple (ASCII) case >> boils down to the same thing. >> >> But, as above and contrary to what I said before, openssl *should* >> work for this case after all, which means you don't need the CA >> to change, which is probably good. (I think it's still confusing >> to people to have almost-identical DNs, but since most people won't >> even know how to look at a certificate, that's less of a problem.) >> >> >s_server.out is the output of the openssl s_server command. >> >> The only error this shows is that one client cert (and card) -- >> I assume client2006.pem -- is rejected for cert expired. >> Which it is; the notAfter is Oct 12 23:59:59 2011 GMT. >> >> >In order to convince the ca's supplier to change the old scard I should: >> >1) Show him the rfc >> >2) Inform all scard users to stop using the old scard >> >3) Give all scard users the new scard >> >Are there some better argumentations to persuade the sa's supplier? >> >> If it were necessary I'd say probably yes, but as above >> I don't think it's necessary. Try using cards (certs) >> that are under the old "2006" root but NOT expired, >> and (now) I'll bet they do work. >> >> Sorry for the unnecessary alarm and confusion. >> >> __ >> 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: Similar issuer dn mod_ssl client authentication issue
Okay, openssl works, but mod_ssl doesn't. Is this a real problem? Instead try hacking mod_ssl code ... Could I ask for a bug/improvement so that mod_ssl could finally work? Michele MAsè On Thu, May 23, 2013 at 1:22 AM, Dave Thompson wrote: > >From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' > >Sent: Tuesday, 21 May, 2013 04:16 > > I was wrong! > > >"Does it work with client=Firefox using client certs under both CAs? > >I would expect at least one to fail. Note that s_server -verify > >doesn't *require* client cert, it only *allows* it; how did you > >check Firefox is actually using your client cert(s)?" > > >I've tested it with both smart card > > I went back and set up a (modified) test and ... I was wrong! > The lookup as such does use the canonical DN and returns only one, > sometimes the wrong one. But I didn't realize X509_STORE_get1_issuer > hiddenly caches *all* the matches and tries them, and (given you > have AKI) *does* select the correct one. So actually your earlier > tries should have worked, or at least not failed for this reason. > > >"The certificates you attached are CA roots and have no AKI. > >pardon, my mistake, I forgot to send the clients certs :( > > >As attachment, there are the client certificates I used. > > And those do indeed have AKI (correctly matching the roots). > > >"I don't know what "exclusive mode" means here." > >virtualhost1 has the ca's bundle made with all certificates + ca1 (for > smart card1) > >virtualhost2 has the ca's bundle made with all certificates + ca2, (for > smart card2); > >the or (exclusive) means you can try virtualhost1 with smart card1 > >or virtualhost2 with scard2 > > Okay. > > >RFC3280 - is it correct? > > > Actually, 3280 has been superseded by 5280, which has more > complicated rules to handle internationalization using > Unicode and IDN, but for this simple (ASCII) case > boils down to the same thing. > > But, as above and contrary to what I said before, openssl *should* > work for this case after all, which means you don't need the CA > to change, which is probably good. (I think it's still confusing > to people to have almost-identical DNs, but since most people won't > even know how to look at a certificate, that's less of a problem.) > > >s_server.out is the output of the openssl s_server command. > > The only error this shows is that one client cert (and card) -- > I assume client2006.pem -- is rejected for cert expired. > Which it is; the notAfter is Oct 12 23:59:59 2011 GMT. > > >In order to convince the ca's supplier to change the old scard I should: > >1) Show him the rfc > >2) Inform all scard users to stop using the old scard > >3) Give all scard users the new scard > >Are there some better argumentations to persuade the sa's supplier? > > If it were necessary I'd say probably yes, but as above > I don't think it's necessary. Try using cards (certs) > that are under the old "2006" root but NOT expired, > and (now) I'll bet they do work. > > Sorry for the unnecessary alarm and confusion. > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
RE: Similar issuer dn mod_ssl client authentication issue
>From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' >Sent: Tuesday, 21 May, 2013 04:16 I was wrong! >"Does it work with client=Firefox using client certs under both CAs? >I would expect at least one to fail. Note that s_server -verify >doesn't *require* client cert, it only *allows* it; how did you >check Firefox is actually using your client cert(s)?" >I've tested it with both smart card I went back and set up a (modified) test and ... I was wrong! The lookup as such does use the canonical DN and returns only one, sometimes the wrong one. But I didn't realize X509_STORE_get1_issuer hiddenly caches *all* the matches and tries them, and (given you have AKI) *does* select the correct one. So actually your earlier tries should have worked, or at least not failed for this reason. >"The certificates you attached are CA roots and have no AKI. >pardon, my mistake, I forgot to send the clients certs :( >As attachment, there are the client certificates I used. And those do indeed have AKI (correctly matching the roots). >"I don't know what "exclusive mode" means here." >virtualhost1 has the ca's bundle made with all certificates + ca1 (for smart card1) >virtualhost2 has the ca's bundle made with all certificates + ca2, (for smart card2); >the or (exclusive) means you can try virtualhost1 with smart card1 >or virtualhost2 with scard2 Okay. >RFC3280 - is it correct? Actually, 3280 has been superseded by 5280, which has more complicated rules to handle internationalization using Unicode and IDN, but for this simple (ASCII) case boils down to the same thing. But, as above and contrary to what I said before, openssl *should* work for this case after all, which means you don't need the CA to change, which is probably good. (I think it's still confusing to people to have almost-identical DNs, but since most people won't even know how to look at a certificate, that's less of a problem.) >s_server.out is the output of the openssl s_server command. The only error this shows is that one client cert (and card) -- I assume client2006.pem -- is rejected for cert expired. Which it is; the notAfter is Oct 12 23:59:59 2011 GMT. >In order to convince the ca's supplier to change the old scard I should: >1) Show him the rfc >2) Inform all scard users to stop using the old scard >3) Give all scard users the new scard >Are there some better argumentations to persuade the sa's supplier? If it were necessary I'd say probably yes, but as above I don't think it's necessary. Try using cards (certs) that are under the old "2006" root but NOT expired, and (now) I'll bet they do work. Sorry for the unnecessary alarm and confusion. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Similar issuer dn mod_ssl client authentication issue
"If these are the roots you attached -- with names that differ only in case of one letter -- they should have gotten the same hashvalue (with suffixes .0 and .1); did they?" yes "Does it work with client=Firefox using client certs under both CAs? I would expect at least one to fail. Note that s_server -verify doesn't *require* client cert, it only *allows* it; how did you check Firefox is actually using your client cert(s)?" I've tested it with both smart card "The certificates you attached are CA roots and have no AKI. AKI can/should be on the *child* certs i.e. your client certs. (The root has *SKI*, which the child AKI normally uses.) But as I said AKI won't fix this with openssl, which uses AKI only as an added check not as a way to select among parent certs." pardon, my mistake, I forgot to send the clients certs :( "I don't know what "exclusive mode" means here." virtualhost1 has the ca's bundle made with all certificates + ca1 (for smart card1) virtualhost2 has the ca's bundle made with all certificates + ca2, (for smart card2); the or (exclusive) means you can try virtualhost1 with smart card1 or virtualhost2 with scard2 RFC3280 - is it correct? 4.1.2.4 Issuer ... This specification requires only a subset of the name comparison functionality specified in the X.500 series of specifications. Conforming implementations are *REQUIRED* to implement the following name comparison rules: (a) attribute values encoded in different types (e.g., PrintableString and BMPString) MAY be assumed to represent different strings; (b) attribute values in types other than PrintableString are case sensitive (this permits matching of attribute values as binary objects); (c) *attribute values in PrintableString are not case sensitive* (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and (d) attribute values in PrintableString are compared after removing leading and trailing white space and converting internal substrings of one or more consecutive white space characters to a single space. As attachment, there are the client certificates I used. s_server.out is the output of the openssl s_server command. In order to convince the ca's supplier to change the old scard I should: 1) Show him the rfc 2) Inform all scard users to stop using the old scard 3) Give all scard users the new scard Are there some better argumentations to persuade the sa's supplier? Best regards Michele Masè On Sat, May 18, 2013 at 12:20 AM, Dave Thompson wrote: > >From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' > >Sent: Friday, 17 May, 2013 10:04 > > >What I did: > > >openssl: > >Commandline for the openssl s_server (sorry for my typo) > >before starting www server: > >c_rehash /some/path #where I've put 2 pem encoded CA's certificates > > If these are the roots you attached -- with names that differ only > in case of one letter -- they should have gotten the same hashvalue > (with suffixes .0 and .1); did they? > > >start the simple www server > >openssl s_server -www -key /some/path/file.key -cert > >/some/path/www.example.com.crt -CApath /some/path -state -verify 10 > > >and testing it with any client (ie firefox) it finally works! > > Does it work with client=Firefox using client certs under both CAs? > I would expect at least one to fail. Note that s_server -verify > doesn't *require* client cert, it only *allows* it; how did you > check Firefox is actually using your client cert(s)? > > >apache + mod_ssl > >No one version worked for me: 2.2.x - 2.4.x (openssl 0.9.8.x - > >openssl 1.x) in various linux configurations (centos[56], ubuntu 13.04) > > Not surprising. This logic hasn't changed in openssl for a long time, > and is the same no matter what program calls it unless the caller > overrides openssl's lookup and/or chain validation. > > >apache + mod_gnutls (have to try it) > > >"It could also be using AKI in chain build, if you have it in > >your certs (I didn't try to go through your script to see). > >OpenSSL *checks* AKI if present but doesn't use for lookup." > > >I attach the original certificates; AKI seems to be ok. > >But this not solves my problem. > > The certificates you attached are CA roots and have no AKI. > AKI can/should be on the *child* certs i.e. your client certs. > (The root has *SKI*, which the child AKI normally uses.) But > as I said AKI won't fix this with openssl, which uses AKI only > as an added check not as a way to select among parent certs. > > >The solution(s) - all put in or (exclusive mode): > > I don't know what "exclusive mode" means here. > > >1) hack mod_ssl or wait indefinitely somebody will do it :( > > The chain validation logic is in openssl. You or someone > would have to change openssl, or else change mod_ssl to > replace (override) at least the lookup logic in OpenSSL > and probably the whole chain validation (because I think > the lookup logic uses already canonicalized DN). > > >2) use mod_gnutls > > If, as I said, GNUTLS can handle
RE: Similar issuer dn mod_ssl client authentication issue
>From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' >Sent: Friday, 17 May, 2013 10:04 >What I did: >openssl: >Commandline for the openssl s_server (sorry for my typo) >before starting www server: >c_rehash /some/path #where I've put 2 pem encoded CA's certificates If these are the roots you attached -- with names that differ only in case of one letter -- they should have gotten the same hashvalue (with suffixes .0 and .1); did they? >start the simple www server >openssl s_server -www -key /some/path/file.key -cert >/some/path/www.example.com.crt -CApath /some/path -state -verify 10 >and testing it with any client (ie firefox) it finally works! Does it work with client=Firefox using client certs under both CAs? I would expect at least one to fail. Note that s_server -verify doesn't *require* client cert, it only *allows* it; how did you check Firefox is actually using your client cert(s)? >apache + mod_ssl >No one version worked for me: 2.2.x - 2.4.x (openssl 0.9.8.x - >openssl 1.x) in various linux configurations (centos[56], ubuntu 13.04) Not surprising. This logic hasn't changed in openssl for a long time, and is the same no matter what program calls it unless the caller overrides openssl's lookup and/or chain validation. >apache + mod_gnutls (have to try it) >"It could also be using AKI in chain build, if you have it in >your certs (I didn't try to go through your script to see). >OpenSSL *checks* AKI if present but doesn't use for lookup." >I attach the original certificates; AKI seems to be ok. >But this not solves my problem. The certificates you attached are CA roots and have no AKI. AKI can/should be on the *child* certs i.e. your client certs. (The root has *SKI*, which the child AKI normally uses.) But as I said AKI won't fix this with openssl, which uses AKI only as an added check not as a way to select among parent certs. >The solution(s) - all put in or (exclusive mode): I don't know what "exclusive mode" means here. >1) hack mod_ssl or wait indefinitely somebody will do it :( The chain validation logic is in openssl. You or someone would have to change openssl, or else change mod_ssl to replace (override) at least the lookup logic in OpenSSL and probably the whole chain validation (because I think the lookup logic uses already canonicalized DN). >2) use mod_gnutls If, as I said, GNUTLS can handle the name-matching differently and nonstandardly. I don't know if it does. >3) put 2 virtualhosts under apache+mod_ssl using two different >cacertifcatefile filename.pem (I must change the server name) Different virtualhosts each with one CAroot would work. Remember for name-based virtualhosts with SSL your clients must support SNI (ServerNameIndication), and you must not have a very old mod_ssl or openssl (about 2 years ago IIRC). For IP-based you need multiple addresses *or* you must get at least one part of your clients to use a nondefault port. And for any virtualhost approach you need DNS entries, and your users must use/select the correct servername (for their CA). >4) use IIS (fool) Some people like IIS, but YMMV. >5) change the issuer DN in CA's For a root cert the issuer and subject must be the same, thus both must change together. But: >Some details: >Unfortunately those (bad) CA's are provided by a thirdy part. >They sign a tons of smart cards. If it's someone else's CA(s), and their roots, only that party can make the change. This look like a new generation (2012-2032 superceding 2006-2018) and you might point out to them that established major CAs like GeoTrust Verisign Thawte use distinct names for new generations. You might also check if cabforum or similar authority has anything to say about this. But even if the CA changes now, there's presumably some population of certs (and cards) already in existence; see your next points. >Sould I ask (force) them to make new brand smart card using another CA? >Could I oblige them to replace all the wrong smart card? If you can get the users/clients to have and use smartcards issued by a CA with a distinct name, that solves the problem. Depending on the smartcard that may or may not be a new card; it may be possible to issue a new cert to an existing card. Whether you have authority or power to force the CA(s) or card issuer(s?) to do new/updated cards, I have no idea. You can probably persuade users to get and use a new or updated card if it's free or very cheap and convenient; if it is costly or inconvenient it depends on what control or influence you have. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Similar issuer dn mod_ssl client authentication issue
Tx. for the response. Now I try to explain what I should do ... What I did: openssl: Commandline for the openssl s_server (sorry for my typo) before starting www server: c_rehash /some/path #where I've put 2 pem encoded CA's certificates start the simple www server openssl s_server -www -key /some/path/file.key -cert /some/path/www.example.com.crt -CApath /some/path -state -verify 10 and testing it with any client (ie firefox) it finally works! apache + mod_ssl No one version worked for me: 2.2.x - 2.4.x (openssl 0.9.8.x - openssl 1.x) in various linux configurations (centos[56], ubuntu 13.04) apache + mod_gnutls (have to try it) "It could also be using AKI in chain build, if you have it in your certs (I didn't try to go through your script to see). OpenSSL *checks* AKI if present but doesn't use for lookup." I attach the original certificates; AKI seems to be ok. But this not solves my problem. The solution(s) - all put in or (exclusive mode): 1) hack mod_ssl or wait indefinitely somebody will do it :( 2) use mod_gnutls 3) put 2 virtualhosts under apache+mod_ssl using two different cacertifcatefile filename.pem (I must change the server name) 4) use IIS (fool) 5) change the issuer DN in CA's Some details: Unfortunately those (bad) CA's are provided by a thirdy part. They sign a tons of smart cards. Sould I ask (force) them to make new brand smart card using another CA? Could I oblige them to replace all the wrong smart card? Michele Masè On Wed, May 15, 2013 at 2:28 AM, Dave Thompson wrote: > >From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' > >Sent: Monday, 13 May, 2013 05:33 > > >I'm testing a client authentication using [Apache with 1.0.0-fips] > >I have 2 CA's x509 pem files, bundled. > >CA1 signs client1 certificate files > >CA2 signs client2 certificate files > > >I should use two different CA with a similar issuer DN_OU > >in a bundle (file /path/to/pemfile.pem) > > >openssl x509 -noout -in one.pem -issuer > >/O=Example S.p.A./OU=CA Organization Unit/ > >openssl x509 -noout -in one.pem -issuer > >/O=Example S.p.A./OU=CA organization Unit/ > >The only difference between 2 CAs is the capital letter in OU field. > > You probably shouldn't. According to RFC 3280 and 5280, X.509 > or X.somethingrelated requires matching of Distinguished Name > including child-Issuer to parent-Subject be case-insensitive > and ignore insignificant (leading,trailing,multiple) spaces. > So what you actually have there is one CA with two certs, > presumably with different (public) keys. If so, certs issued > under one can't verify under the other. > > OpenSSL does cert (chain) lookup using canonicalized DN and > takes the first one found, so if you have "canonically-equal" > names like these (which both match) it can only use one. > > >When i try to use this configuration I receive a 403 error: > >AH02261: Re-negotiation handshake failed: Not accepted by client!? > > That looks like a different error or at least a confusing message. > > >The only way it works is without [requiring client auth] or > >Using only one CA in the file (file /path/to/pemfile.pem) > > As expected, see above. > > >But I'm still unable to retrieve client cert data; I don't know > >if the client is authenticated or not. > > I don't know what if anything mod_ssl gives you if it receives > a client cert that doesn't validate. But I would focus on getting > client auth to work first, and then see if you have a problem > with getting the auth result. > > >The same configuration using openssl_server works, it seems like > >an uncorrect (or incomplete) mod_ssl openssl's implementation. > > Do you mean commandline s_server? That shouldn't verify a client cert > that mod_ssl doesn't with the same truststore, but it *will* proceed > with a session even if a cert fails to verify, whereas a proper SSL > application will refuse to continue or at least treat as unauthorized. > Look to see if s_server reported any "verify error:...". > > If you mean something else, you'll have to explain. > > >[If] The bundle file contains CA1 and CA2; client certificates > >signed by CA1 (client1) work, client certificates signed by CA2 > >(client2) don't work. [and if reversed the reverse] > > As expected, OpenSSL uses only the first matching CA cert. > > >The same site under iis works :( > > I don't know much about IIS but I would guess it uses the > same Windows logic for trust as browsers like IE and Chrome, > and I know those do find alternate chains in some cases > OpenSSL's method does not -- even for identical CA-name, &
RE: Similar issuer dn mod_ssl client authentication issue
>From: owner-openssl-us...@openssl.org On Behalf Of Michele Mase' >Sent: Monday, 13 May, 2013 05:33 >I'm testing a client authentication using [Apache with 1.0.0-fips] >I have 2 CA's x509 pem files, bundled. >CA1 signs client1 certificate files >CA2 signs client2 certificate files >I should use two different CA with a similar issuer DN_OU >in a bundle (file /path/to/pemfile.pem) >openssl x509 -noout -in one.pem -issuer >/O=Example S.p.A./OU=CA Organization Unit/ >openssl x509 -noout -in one.pem -issuer >/O=Example S.p.A./OU=CA organization Unit/ >The only difference between 2 CAs is the capital letter in OU field. You probably shouldn't. According to RFC 3280 and 5280, X.509 or X.somethingrelated requires matching of Distinguished Name including child-Issuer to parent-Subject be case-insensitive and ignore insignificant (leading,trailing,multiple) spaces. So what you actually have there is one CA with two certs, presumably with different (public) keys. If so, certs issued under one can't verify under the other. OpenSSL does cert (chain) lookup using canonicalized DN and takes the first one found, so if you have "canonically-equal" names like these (which both match) it can only use one. >When i try to use this configuration I receive a 403 error: >AH02261: Re-negotiation handshake failed: Not accepted by client!? That looks like a different error or at least a confusing message. >The only way it works is without [requiring client auth] or >Using only one CA in the file (file /path/to/pemfile.pem) As expected, see above. >But I'm still unable to retrieve client cert data; I don't know >if the client is authenticated or not. I don't know what if anything mod_ssl gives you if it receives a client cert that doesn't validate. But I would focus on getting client auth to work first, and then see if you have a problem with getting the auth result. >The same configuration using openssl_server works, it seems like >an uncorrect (or incomplete) mod_ssl openssl's implementation. Do you mean commandline s_server? That shouldn't verify a client cert that mod_ssl doesn't with the same truststore, but it *will* proceed with a session even if a cert fails to verify, whereas a proper SSL application will refuse to continue or at least treat as unauthorized. Look to see if s_server reported any "verify error:...". If you mean something else, you'll have to explain. >[If] The bundle file contains CA1 and CA2; client certificates >signed by CA1 (client1) work, client certificates signed by CA2 >(client2) don't work. [and if reversed the reverse] As expected, OpenSSL uses only the first matching CA cert. >The same site under iis works :( I don't know much about IIS but I would guess it uses the same Windows logic for trust as browsers like IE and Chrome, and I know those do find alternate chains in some cases OpenSSL's method does not -- even for identical CA-name, so I would expect also for canonically-equal CA-name. It could also be using AKI in chain build, if you have it in your certs (I didn't try to go through your script to see). OpenSSL *checks* AKI if present but doesn't use for lookup. >How could I solve it using apache? I doubt you can use those CAs with vanilla mod_ssl and openssl. You could build and use a hacked version of openssl that does (more) exact lookup and match. If you want this to work over time you'd have to periodically redo a new version. I've not seen any CA that actually used the freedom to make child.Issuer "insignificantly" different. I believe there is (still?) an option for httpd to use GNUTLS instead of OpenSSL. I have no idea if that behaves differently (nonstandardly) or if it can be made to. But better is to use clearly different names for your CAs. Even if you can get programs to distinguish them, people looking at these certs will have trouble. Most "real" (public) CAs use long similar but (canonically) unequal names like Fred and Tony's Super Premium Wonderful Certificates Class 45 Red Blue Fred and Tony's Super Premium Wonderful Certificates Class 45 Blue Red and I have often wasted time as a result of confusing them. I'd much rather see "Left Client CA" and "Right Client CA" or whatever your actual divisions/purposes are. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Similar issuer dn mod_ssl client authentication issue
I'm testing a client authentication using: SSLCACertificateFile /path/to/pemfile.pem SSLVerifyClient require SSLVerifyDepth 2 /LocationMatch> My env: CentOS 6.4, OpenSSL 1.0.0-fips 29 Mar 2010, Server version: Apache/2.4.3 (Unix) - Server built: Feb 7 2013 14:32:46 I have 2 CA's x509 pem files, bundled. CA1 signs client1 certificate files CA2 signs client2 certificate files I should use two different CA with a similar issuer DN_OU in a bundle (file /path/to/pemfile.pem) openssl x509 -noout -in one.pem -issuer /C=IT/ST=MyState/L=MyTown/CN=Example Root CA Temporary 90days/O=Example S.p.A./OU=CA *O*rganization Unit/emailAddress=i...@example.com openssl x509 -noout -in one.pem -issuer /C=IT/ST=MyState/L=MyTown/CN=Example Root CA Temporary 90days/O=Example S.p.A./OU=CA *o*rganization Unit/emailAddress=i...@example.com The only difference between 2 CAs is the capital letter in OU field. When i try to use this configuration I receive a 403 error: [Mon May 06 09:33:28.115455 2013] [ssl:error] [pid 5120:tid 139860297901824] [client 10.0.2.2:59798] AH02261: Re-negotiation handshake failed: Not accepted by client!? The only way it works is without the SSLRequire directive. or Using only one CA in the file (file /path/to/pemfile.pem) or using SSLVerifyClient optional|optional_no_ca But I'm still unable to retrieve client cert data; I don't know if the client is authenticated or not. The same configuration using openssl_server works, it seems like an uncorrect (or incomplete) mod_ssl openssl's implementation. Addendum: The bundle file contains CA1 and CA2; client certificates signed by CA1 (client1) work, client certificates signed by CA2 (client2) don't work. If I change the order of the two certificates in the /path/to/pemfile.pem, it happens that: The budle file contains CA2 and CA1; client certificates signed by CA2 (client2) work, client certificates signed by CA1 (client1) don't work. The same site under iis works :( How could I solve it using apache? Some suggestions? Regards Michele Masè ps: no aswer from apache mailing list :( I've attached a sample script to create CA's and client certificates. cert-gen.sh Description: Bourne shell script
Re: TLS 1.2 client authentication
On Mon, Oct 01, 2012, Thulasi wrote: > Hello all, > > I've a problem with TLS 1.2 client authentication where client has 512-bit > RSA key and certificate and signature hash is of sha512. > This is reproducible with openssl-1.0.1c and many prior versions which > support TLS 1.2 client authentication. > While calculating CCV (client cert verify data), I fail to calculate RSA > signature over verify data which is greater than 53 (64-11) bytes as sha512 > verify data is of 64 bytes. > I understand that 512 bit certificates are too weak to be used in > real-time. But in theory, is there any alternative to solve this problem? > You could in theory modify OpenSSL to use a smaller digest if the key is too small. But as you say the key is too weak and the correct solution is to use a larger key. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
client authentication between OpenSSL and .NET SSLStream
I have an existing server application in QNX using OpenSSL 0.9.8m. With a client application in Windows 7 using .NET 4 SSLStreams. I've generated my own certificates using openssl for server and client. Everything is working as it did before the modifications. I'm using extended fields into the client cert to verify the role of the client. I used the SSL_VERIFY_PEER switch for the SSL_CTX_set_verify call. Using wireshark, the server send its cert during the SSL handshake. I do not see the client send its certificate back to the server. I executed: "openssl s_client -cert client.pem -connect 192.168.101.185:5311 -tls1". Using wireshark, both the client and the server certificates were transfer ok. I can't get the client using SSLStreams to send its cert to the server. I have used both .NET 3.5 or .NET 4. Is there an interoperability problem here. Or some misconfiguration mistake I have made in.NET? Has anyone done this before? Thanks in advance Roy __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Will OpenSSL support DTLS client authentication using ECDH certificate?
On 10/8/10, daniel.war...@gdc4s.com wrote: > Using 1.0.0a s_server and s_client I was able to get TLS server only > authentication and client and server authentication using ECDH > certificates to work. > Using 1.0.0a s_server and s_client I was not able to get DTLS to work. > I found a comment in the code that > For now, we do not support client authentication using ECDH > certificates. > Will OpenSSL add support for DTLS client authentication using ECDH > certificate? > Also does anyone know why my DTLS EC server authentication failed? > > TLS EC Server Authentication > openssl s_server -accept 9001 -cert certs/secp256r1TestServer.pem -key > private/secp256r1TestServer.key -CAfile ./ca-certs/secp256r1TestCA.pem > -cipher ECDHE-ECDSA-AES256-SHA > openssl s_client -connect localhost:9001 -CAfile > ./ca-certs/secp256r1TestCA.pem -cipher ECDHE-ECDSA-AES256-SHA > Shared ciphers:ECDHE-ECDSA-AES256-SHA > CIPHER is ECDHE-ECDSA-AES256-SHA > > TLS EC Client and Server Authentication > openssl s_server -accept 9001 -cert certs/secp256r1TestServer.pem -key > private/secp256r1TestServer.key -CAfile ./ca-certs/secp256r1TestCA.pem > -cipher ECDHE-ECDSA-AES256-SHA > openssl s_client -connect localhost:9001 -cert > certs/secp256r1TestClient.pem -key private/secp256r1TestClient.key > -CAfile ./ca-certs/secp256r1TestCA.pem -cipher ECDHE-ECDSA-AES256-SHA > Shared ciphers:ECDHE-ECDSA-AES256-SHA > CIPHER is ECDHE-ECDSA-AES256-SHA > > DTLS EC Server Authentication > openssl s_server -dtls1 -accept 9001 -cert certs/secp256r1TestServer.pem > -key private/secp256r1TestServer.key -CAfile > ./ca-certs/secp256r1TestCA.pem -cipher ECDHE-ECDSA-AES256-SHA > Using default temp DH parameters > Using default temp ECDH parameters > ACCEPT > ERROR > 5932:error:1408A044:SSL routines:SSL3_GET_CLIENT_HELLO:internal > error:s3_srvr.c: > 725: > shutting down SSL > CONNECTION CLOSED > > openssl s_client -dtls1 -connect localhost:9001 -CAfile > ./ca-certs/secp256r1TestCA.pem -cipher ECDHE-ECDSA-AES256-SHA > CONNECTED(0003) > 6092:error:14102410:SSL routines:DTLS1_READ_BYTES:sslv3 alert handshake > failure: > d1_pkt.c:963:SSL alert number 40 > 6092:error:1410C0E5:SSL routines:DTLS1_WRITE_APP_DATA_BYTES:ssl > handshake failure:d1_pkt.c:1153: > > Dan Warren > > > -- Sent from my mobile device __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Will OpenSSL support DTLS client authentication using ECDH certificate?
Using 1.0.0a s_server and s_client I was able to get TLS server only authentication and client and server authentication using ECDH certificates to work. Using 1.0.0a s_server and s_client I was not able to get DTLS to work. I found a comment in the code that For now, we do not support client authentication using ECDH certificates. Will OpenSSL add support for DTLS client authentication using ECDH certificate? Also does anyone know why my DTLS EC server authentication failed? TLS EC Server Authentication openssl s_server -accept 9001 -cert certs/secp256r1TestServer.pem -key private/secp256r1TestServer.key -CAfile ./ca-certs/secp256r1TestCA.pem -cipher ECDHE-ECDSA-AES256-SHA openssl s_client -connect localhost:9001 -CAfile ./ca-certs/secp256r1TestCA.pem -cipher ECDHE-ECDSA-AES256-SHA Shared ciphers:ECDHE-ECDSA-AES256-SHA CIPHER is ECDHE-ECDSA-AES256-SHA TLS EC Client and Server Authentication openssl s_server -accept 9001 -cert certs/secp256r1TestServer.pem -key private/secp256r1TestServer.key -CAfile ./ca-certs/secp256r1TestCA.pem -cipher ECDHE-ECDSA-AES256-SHA openssl s_client -connect localhost:9001 -cert certs/secp256r1TestClient.pem -key private/secp256r1TestClient.key -CAfile ./ca-certs/secp256r1TestCA.pem -cipher ECDHE-ECDSA-AES256-SHA Shared ciphers:ECDHE-ECDSA-AES256-SHA CIPHER is ECDHE-ECDSA-AES256-SHA DTLS EC Server Authentication openssl s_server -dtls1 -accept 9001 -cert certs/secp256r1TestServer.pem -key private/secp256r1TestServer.key -CAfile ./ca-certs/secp256r1TestCA.pem -cipher ECDHE-ECDSA-AES256-SHA Using default temp DH parameters Using default temp ECDH parameters ACCEPT ERROR 5932:error:1408A044:SSL routines:SSL3_GET_CLIENT_HELLO:internal error:s3_srvr.c: 725: shutting down SSL CONNECTION CLOSED openssl s_client -dtls1 -connect localhost:9001 -CAfile ./ca-certs/secp256r1TestCA.pem -cipher ECDHE-ECDSA-AES256-SHA CONNECTED(0003) 6092:error:14102410:SSL routines:DTLS1_READ_BYTES:sslv3 alert handshake failure: d1_pkt.c:963:SSL alert number 40 6092:error:1410C0E5:SSL routines:DTLS1_WRITE_APP_DATA_BYTES:ssl handshake failure:d1_pkt.c:1153: Dan Warren
Re: "Unable to configure verify locations for client authentication"
On first glance, it's rather stupid, but Apache (partly due to baggage from the underlying OpenSSL, but this baggage was unavoidable) requires the end-entity certificate (the certificate which contains the public key for which you have the private key) to be loaded separately from the chain that leads to the trust anchor. However, it becomes a bit clearer why this is the case when you consider that an X.509 certificate has absolutely nothing within itself to identify how deep its trust structure is. This is intentional, as a CA Alpha could become trusted by another CA Beta. CA Beta has a huge trust base, while CA Alpha has a very small one. If the end-entity certificate EEAlpha were issued by an intermediate A' issued by Alpha, A' would know that it was 1 step down, and EEAlpha would know that it was 2 steps down. However, because of the cross-certificate potential (Beta certifies Alpha), EEAlpha could potentially be either 3 or 4 steps away from a widely-used trust anchor (depending on how you count it). What the SSLCertificateChainFile directive is is the list of intermediate certificates between the end-entity and a widely-used trust anchor. (You're right, it doesn't have 'CA' in it. It's confusing enough to those of us who know it.) The 'trust anchor' is, technically, the CA public key that's embedded in the client software. You need to get something signed by the CA root private key which states that it's authorized to act as an intermediate CA, that in turn signs something that may be the end-entity certificate or may be another intermediate CA, and you need every one of those intermediate certificates including the one that signed your end-entity certificate (the one in the Issuer field, the one identified by the Authority Key Identifier extension). I consider it a bug in the TLS protocol that multiple peer identities (either server or client) cannot be proffered simultaneously, and that there is the potential to rely on the CA Key extension (which has the potential to lead to a very difficult-to-troubleshoot situation absent custom tools) to form the basis for a multiply-identified server which owner was trying to manage its risks by having EE certs from more than a single provider. -Kyle H On Thu, Aug 12, 2010 at 3:07 PM, Bill Moseley wrote: On Thu, Aug 12, 2010 at 1:56 PM, wrote: You're looking at a couple of issues here. (First, please be aware that this is the OpenSSL users list, not necessary a mod_ssl support list; however, since they're intertwined, we do have some knowledge of mod_ssl.) Plus, single-to-noise ration is quite good here. ;) What you need to do is change that from 'SSLCACertificateFile' to 'SSLCACertificateChainFile'. So you mean combine my certificate and the intermediate certificate? cat my_site.crt intermediate.crt > bundle.crt SSLCACertificateChainFile /etc/apache2/ssl/bundle.crt Invalid command 'SSLCACertificateChainFile', perhaps mis-spelled or defined by a module not included in the server configuration There's SSLCertificateChainFile, but if I set that w/o SSLCertificateFile I get: [error] Server should be SSL-aware but has no certificate configured [Hint: SSLCertificateFile] And with SSLCertificateFile and SSLCertificateChainFile set I still have the same issue that some browsers report: The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) In Firefox, but Chrome accepts it fine. Again, I am not using client authentication. Thanks, -- Bill Moseley mose...@hank.org smime.p7s Description: S/MIME Cryptographic Signature
Re: "Unable to configure verify locations for client authentication"
On Thu, Aug 12, 2010 at 1:56 PM, wrote: > You're looking at a couple of issues here. (First, please be aware that > this is the OpenSSL users list, not necessary a mod_ssl support list; > however, since they're intertwined, we do have some knowledge of mod_ssl.) > Plus, single-to-noise ration is quite good here. ;) > What you need to do is change that from 'SSLCACertificateFile' to > 'SSLCACertificateChainFile'. So you mean combine my certificate and the intermediate certificate? cat my_site.crt intermediate.crt > bundle.crt SSLCACertificateChainFile /etc/apache2/ssl/bundle.crt Invalid command 'SSLCACertificateChainFile', perhaps mis-spelled or defined by a module not included in the server configuration There's SSLCertificateChainFile, but if I set that w/o SSLCertificateFile I get: [error] Server should be SSL-aware but has no certificate configured [Hint: SSLCertificateFile] And with SSLCertificateFile and SSLCertificateChainFile set I still have the same issue that some browsers report: The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) In Firefox, but Chrome accepts it fine. Again, I am not using client authentication. Thanks, -- Bill Moseley mose...@hank.org
Re: "Unable to configure verify locations for client authentication"
You're looking at a couple of issues here. (First, please be aware that this is the OpenSSL users list, not necessary a mod_ssl support list; however, since they're intertwined, we do have some knowledge of mod_ssl.) What you need to do is change that from 'SSLCACertificateFile' to 'SSLCACertificateChainFile'. The documentation on SSLCACertificateChainFile: This directive sets the optional all-in-one file where you can assemble the certificates of Certification Authorities (CA) which form the certificate chain of the server certificate. This starts with the issuing CA certificate of of the server certificate and can range up to the root CA certificate. Such a file is simply the concatenation of the various PEM-encoded CA Certificate files, usually in certificate chain order. NOTE: If you do not construct the path properly by hand, SSLCACertificateChainFile *WILL* cause ALL of the certificates in the chain file to be inserted (after decoding to DER) into the certificate chain in the TLS layer. This causes a violation of the TLS and SSLv3 protocols (and is arguably a bug, though I haven't taken the time to sit down and generate a simple test case). Thus, please *only* place the certificates that are necessary to chain up to a presumably-known-to-the-client CA. If you are not using client authentication, then you don't need any CAs set up for Client Verification. If you are, you need to set up a separate list of CAs from which you will accept certificates, include their certificates into a .PEM encoded/all-certs-concatenated file, and use that for SSLCACertificateFile with SSLVerifyClient 'optional_no_ca' or 'required'. (I've always liked optional_no_ca, since it allows me to provide my own interface for 'Okay, you've provided a certificate, but it's not one that we understand. Please click here to try again.' (where 'click here' removes the server cache object), or 'You haven't provided a certificate, and we need one to know who you are. Please click here to try again.') -Kyle H On Thu, Aug 12, 2010 at 1:02 PM, Bill Moseley wrote: I am not trying to set up client auth on Apache, just install a new SSL certificate. The instructions[1] for the new certificate says to install and intermediate certificate: SSLCACertificateFile /usr/local/ssl/crt/intermediate.crt I've done that, confirmed the paths and the certificate, but apache reports: [error] Unable to configure verify locations for client authentication If I comment out that directive in httpd.conf the server starts fine and the site works ok for some newer browsers but older browsers (including FF3.6.8) report that the CA is unknown. Searching Google for that error message I find mostly people trying to set up client auth, which I'm not trying to do. For example: http://www.mail-archive.com/modssl-us...@modssl.org/msg17547.html, but again that user was trying to set up client auth, plus SSLCADNRequestFile is not a known config setting in my environment. Running an old version of Apache, unfortunately: Apache/2.0.54 (Debian GNU/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7e Any ideas? Thanks, [1] https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=SO15167 -- Bill Moseley mose...@hank.org smime.p7s Description: S/MIME Cryptographic Signature
"Unable to configure verify locations for client authentication"
I am not trying to set up client auth on Apache, just install a new SSL certificate. The instructions[1] for the new certificate says to install and intermediate certificate: SSLCACertificateFile /usr/local/ssl/crt/intermediate.crt I've done that, confirmed the paths and the certificate, but apache reports: [error] Unable to configure verify locations for client authentication If I comment out that directive in httpd.conf the server starts fine and the site works ok for some newer browsers but older browsers (including FF3.6.8) report that the CA is unknown. Searching Google for that error message I find mostly people trying to set up client auth, which I'm not trying to do. For example: http://www.mail-archive.com/modssl-us...@modssl.org/msg17547.html, but again that user was trying to set up client auth, plus SSLCADNRequestFile is not a known config setting in my environment. Running an old version of Apache, unfortunately: Apache/2.0.54 (Debian GNU/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7e Any ideas? Thanks, [1] https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=SO15167 -- Bill Moseley mose...@hank.org
Error with client authentication from OpenSSL 0.9.8l
Dear sirs,
I have a trouble with OpenSSL with Apache web server.
With client authentication, web browsers cannot connect to web server.
Apache log file of logs/erro_log shows as follows:
[Fri May 14 11:45:05 2010] [info] [client 192.168.220.169] Connection to
child 1 established (server mstestsv2.globalsign.co.jp:443)
[Fri May 14 11:45:05 2010] [info] Seeding PRNG with 136 bytes of entropy
[Fri May 14 11:45:05 2010] [debug] ssl_engine_kernel.c(1866): OpenSSL:
Handshake: start
[Fri May 14 11:45:05 2010] [debug] ssl_engine_kernel.c(1874): OpenSSL: Loop:
before/accept initialization
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1882): OpenSSL: read
11/11 bytes from BIO#95acc20 [mem: 959b940] (BIO dump follows)
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1815):
+-+
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | : 16 03 01
01 ac 01 00 01-a8 03 01 ... |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1860):
+-+
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1882): OpenSSL: read
422/422 bytes from BIO#95acc20 [mem: 959b94e] (BIO dump follows)
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1815):
+-+
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | : 4b ec be
9f 33 bb 31 21-3b 45 ed 13 75 83 ab 3e K...3.1!;E..u..> |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0010: 93 cb 5a
97 da 6d e9 75-7b 8f 3a 42 35 47 d6 13 ..Z..m.u{.:B5G.. |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0020: 20 84 00
a8 f7 b0 c2 b8-6e 95 c9 29 21 5f 72 6d ...n..)!_rm |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0030: 00 02 6c
d0 8d 1d 3a 8a-70 50 de a0 e1 be 81 7e ..l...:.pP.~ |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0040: d3 00 46
c0 0a c0 14 00-88 00 87 00 39 00 38 c0 ..F.9.8. |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0050: 0f c0 05
00 84 00 35 c0-07 c0 09 c0 11 c0 13 00 ..5. |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0060: 45 00 44
00 33 00 32 c0-0c c0 0e c0 02 c0 04 00 E.D.3.2. |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0070: 96 00 41
00 04 00 05 00-2f c0 08 c0 12 00 16 00 ..A./... |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0080: 13 c0 0d
c0 03 fe ff 00-0a 01 00 01 19 00 00 00 |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0090: 1f 00 1d
00 00 1a 6d 73-74 65 73 74 73 76 32 2e ..mstestsv2. |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 00a0: 67 6c 6f
62 61 6c 73 69-67 6e 2e 63 6f 2e 6a 70 globalsign.co.jp |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 00b0: 00 0a 00
08 00 06 00 17-00 18 00 19 00 0b 00 02 |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 00c0: 01 00 00
23 00 e0 15 ca-18 02 31 9a 99 12 12 97 ...#..1. |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 00d0: 91 66 60
79 ae 5a 15 ae-99 54 38 84 4f 10 b5 23 .f`y.Z...T8.O..# |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 00e0: fc 3f d9
0a 63 3b 44 fc-6a e6 98 fc 05 da a4 86 .?..c;D.j... |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 00f0: ae 83 e2
05 7e 4a 7d 9a-2f b4 c8 57 77 ce 8a 78 ~J}./..Ww..x |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0100: 9b 9e 4a
24 f2 37 e3 2c-91 20 aa 92 e8 7c d7 72 ..J$.7.,. ...|.r |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0110: 04 de a8
68 59 4e 05 d2-9b 06 dd d5 cb 1a f6 b6 ...hYN.. |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0120: 52 45 73
c2 8c e8 5a b9-7b bc 06 11 6d 6b ff 6e REs...Z.{...mk.n |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0130: 12 48 75
71 02 1e f9 d5-bb 79 27 1d d7 39 3d 41 .Huq.y'..9=A |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0140: 18 29 cf
f1 92 a7 81 98-01 fc ae 0e c9 de 3b 4e .);N |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0150: 56 aa 7f
75 f9 8a cf a6-5d af fe bd 2f d2 79 25 V..u].../.y% |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0160: 85 94 9d
26 e0 19 7e f2-47 d6 e2 67 2c a0 69 cb ...&..~.G..g,.i. |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0170: 3b f6 38
e7 74 7b 02 13-a5 8c 93 01 7f 6c 92 64 ;.8.t{...l.d |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0180: ce b0 c9
02 00 fc 27 c8-fe 67 da 75 29 a9 1d 48 ..'..g.u)..H |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 0190: 5f 41 1b
7a 8a 0f c8 89-95 fe b4 cf bb 20 71 51 _A.z. qQ |
[Fri May 14 11:45:05 2010] [debug] ssl_engine_io.c(1854): | 01a0:
Re: client authentication and tokens.
Peter Gubis wrote: On 13. 3. 2010 0:37, John R Pierce wrote: our security auditors yanked the token out, and the client continues to work, .. you'll probably need to listen for token removal event and destroy this ssl session after that. It is working for us in this way. Session should be renegotiated after token is inserted again. this has migrated towards being a tomcat problem, I think. we would like to enforce renegotation after each top level transaction in our server app by closing the SSL socket, so the client is forced to restart the SSL socket and renegotiate the session secret via its token based private key. now, I know SSL sessions have some retry/resume capability, we need to force the client to start the whole SSL session over. what server action on an open SSL socket will ensure an OpenSSL 0.9.8 client starts all over and doesn't try and restart/resume the existing session? should we send an SSL Alert then closing the socket ? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: client authentication and tokens.
On 13. 3. 2010 0:37, John R Pierce wrote: > we have a client-server application pair (ok, the server side is > tomcat), the client is using an Aladdin eToken w/ openssl and > engine_pkcs11 and aladdin's driver. thats all fine and working now. > the client application has long running persistence, eg, once its > running, it stays up for days/weeks as its a dedicated system sort of > thing. the client makes periodic queries to the tomcat server, > server responsds, yada yada yada... > our security auditors yanked the token out, and the client continues > to work, like its cached the SSL authentication and continues to reuse > the same session. > > so, what exactly should we be doing from our xmlrpc-over-ssl client to > ensure each of our macro "transactions" re-authenticates from scratch? > > Hi, you'll probably need to listen for token removal event and destroy this ssl session after that. It is working for us in this way. Session should be renegotiated after token is inserted again. Regards, Peter __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
client authentication and tokens.
we have a client-server application pair (ok, the server side is tomcat), the client is using an Aladdin eToken w/ openssl and engine_pkcs11 and aladdin's driver. thats all fine and working now. the client application has long running persistence, eg, once its running, it stays up for days/weeks as its a dedicated system sort of thing. the client makes periodic queries to the tomcat server, server responsds, yada yada yada... our security auditors yanked the token out, and the client continues to work, like its cached the SSL authentication and continues to reuse the same session. so, what exactly should we be doing from our xmlrpc-over-ssl client to ensure each of our macro "transactions" re-authenticates from scratch? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Client-Authentication using Crypt::SSLeay
Hi all,
there was a little cut-n-paste error in my previous mail,
I forgot one line in the script. The error remains the
same...
Olaf Gellert wrote:
> $file=$ENV{HTTPS_PKCS12_FILE};
$pass=$ENV{HTTPS_PKCS12_PASSWORD};
> $ctx->use_pkcs12_file($file ,$pass) || die("failed to load $file: $!");
Cheers, Olaf
--
Olaf Gellert email gell...@dkrz.de
Deutsches Klimarechenzentrum GmbH phone +49 (0)40 41173 214
Bundesstrasse 55 fax+49 (0)40 41173 270
D-20146 Hamburg, Germany wwwhttp://www.dkrz.de
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Client-Authentication using Crypt::SSLeay
I am trying to open an SSL connection with Client Authentication
using Crypt::SSLeay.
What works fine is specifying environment variables
HTTPS_CERT_FILE and HTTPS_KEY_FILE. Unfortunately
the keyfile has to be unencrypted (there seems to
be no no password mechanism for HTTPS_KEY_FILE).
When I try to use HTTPS_PKCS12_FILE and
HTTPS_PKCS12_PASSWORD, Crypt::SSLeay seems to be unable
to open the PKCS12 file. On calling use_pkcs12_file
it returns an error "No such file or directory" (though
strace reveals that the file exists and is opened).
This is what I do:
##
$ENV{HTTPS_PKCS12_FILE} = '/home/gellert/test-cert.p12';
$ENV{HTTPS_PKCS12_PASSWORD} = 'test';
$ENV{HTTPS_VERSION} = 3;
$ENV{HTTPS_DEBUG} = 1;
require Crypt::SSLeay;
sub _default_context {
require Crypt::SSLeay::MainContext;
Crypt::SSLeay::MainContext::main_ctx(@_);
}
my $ctx = _default_context(23);
$file=$ENV{HTTPS_PKCS12_FILE};
$ctx->use_pkcs12_file($file ,$pass) || die("failed to load $file: $!");
#
This is the output of the script:
#
./test.pl
failed to load /home/gellert/test-cert.p12: No such file or
directory at ./test.pl line 27.
#
And this is what strace says...
#
open("/etc/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/home/gellert/test-cert.p12", O_RDONLY) = 3
[...]
read(3,
"0\202\n\351\2\1\0030\202\n\257\6\t*\206H\206\367\r\1\7\1\240\202\n\240\4\202\n\2340\202"...,
4096) = 2797
close(3)= 0
munmap(0x7f448c5fd000, 4096)= 0
write(2, "failed to load /home/gellert/tes"..., 149failed to load
/home/gellert/test-cert.p12: No such file or directory at ./test.pl line 27.
#
The PKCS12 file was generated using OpenSSL, so this should
work...
By the way: Funny that use_pkcs12_file() still tries to open
/etc/ssl/cert.pem, even if a certificate file is specified...
Any idea? Or can I work around this using PEM-key and certificate
(but the key has to be encrypted)...
Cheers, Olaf
--
Olaf Gellert email gell...@dkrz.de
Deutsches Klimarechenzentrum GmbH phone +49 (0)40 41173 214
Bundesstrasse 55 fax+49 (0)40 41173 270
D-20146 Hamburg, Germany wwwhttp://www.dkrz.de
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Client Authentication Certificates
Hi all, I am trying to get the client authentication working in my embedded application. The SSL implementation in my device is a openssl porting. The server application does not implement SSL, so I am using the stunnel. When I set the verify level to 2 (which the server should ask for the client cert) I am getting the following error: -- 2008.11.26 16:48:23 LOG7[5392:6100]: SSL state (accept): before/accept initialization 2008.11.26 16:48:23 LOG7[5392:6100]: SSL state (accept): SSLv3 read client hello A 2008.11.26 16:48:23 LOG7[5392:6100]: SSL state (accept): SSLv3 write server hello A 2008.11.26 16:48:23 LOG7[5392:6100]: SSL state (accept): SSLv3 write certificate A 2008.11.26 16:48:23 LOG7[5392:6100]: SSL state (accept): SSLv3 write certificate request A 2008.11.26 16:48:23 LOG7[5392:6100]: SSL state (accept): SSLv3 flush data 2008.11.26 16:48:25 LOG7[5392:6100]: SSL alert (read): fatal: certificate expired 2008.11.26 16:48:25 LOG3[5392:6100]: SSL_accept: 14094415: error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate expired 2008.11.26 16:48:25 LOG5[5392:6100]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket -- In my client device I get the error: Certificate has expired. Certificate is not valid Yet 'Nov 22 19:00:09 2018 GMT'. I am not sure if the problem is my software or the stunnel. My first guess is my certificates, I am not sure if I'm creating them correctly. The following blocks show how I am creating them. Generating the CA -- SET CAreq=ca.crq SET CAcert=cacert.pem SET CAkey=cakey.pem openssl genrsa -out %CAkey% 1024 openssl req -config testecnf.cnf -new -key %CAkey% -out %CAreq% openssl ca -extensions v3_ca -config testecnf.cnf -days 3650 -keyfile %CAkey% -out %CAcert% -selfsign -infiles %CAreq% -- Generating Server Cert -- SET SKSreq=SKS.crq SET SKScert=SKScert.pem SET SKSkey=SKSkey.pem openssl genrsa -out %SKSkey% 1024 openssl req -config testecnf.cnf -new -key %SKSkey% -out %SKSreq% openssl ca -policy policy_anything -config testecnf.cnf -cert %CAcert% -days 365 -keyfile %CAkey% -out %SKScert% -infiles %SKSreq% -- Generating Client Cert -- SET SKGreq=SKG.crq SET SKGcert=SKGcert.pem SET SKGkey=SKGkey.pem openssl genrsa -out %SKGkey% 1024 openssl req -config testecnf.cnf -new -key %SKGkey% -out %SKGreq% openssl ca -policy policy_anything -config testecnf.cnf -cert %CAcert% -days 365 -keyfile %CAkey% -out %SKGcert% -infiles %SKGreq% -- Is there something wrong? Thanks in advance, Mauricio
Re: How to create a CRT certificate for client authentication
Hi there; On June 3, 2008 11:37:19 am staggerwing wrote: > Hello, > > I have installed OpenSSL on Windows and I want to create a CRT certificate > for client authentication purposes. I want specific clients to > authenticate against a Windows 2003 web server. > > Windows 2003 CA does not allow me to create a CRT certificate but only CER. > The customer is using an in house java application and requires CRT. > Ah - what you want is PEM? and not the DER encoding that Microsoft provides? (PEM is Base64 encoded certificate, DER is a binary format). If the client wants a "crt" that is actually a DER encoded , just change the extension and give it to them (CER is pretty much just a DER encoded cert). If the client wants a "crt" that is actually a PEM encoded cert: openssl x509 -in cert.cer -inform DER -out cert.crt -outform PEM will do what you want. > Any help, hind, link or anything else is greatly appreciated as I am at an > dead end :( > Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
How to create a CRT certificate for client authentication
Hello, I have installed OpenSSL on Windows and I want to create a CRT certificate for client authentication purposes. I want specific clients to authenticate against a Windows 2003 web server. Windows 2003 CA does not allow me to create a CRT certificate but only CER. The customer is using an in house java application and requires CRT. Any help, hind, link or anything else is greatly appreciated as I am at an dead end :( Regards, Chris -- View this message in context: http://www.nabble.com/How-to-create-a-CRT-certificate-for-client-authentication-tp17626540p17626540.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 [EMAIL PROTECTED]
Re: Client authentication using Certificate chain.
Hi Ma'm, I am a faculty in an Engg. College, AP. I need to teach my students abt OpenSSL. Can u help me with appropriate material and simple C programs to work on Windows. regards, kalyan On 3/13/08, Bhat, Jayalakshmi Manjunath <[EMAIL PROTECTED]> wrote: > > Hi All, > > If client authentication requested by the server, is it MUST to send the > certificate chain along with client certificate? Does RFC mandates sending > certificate chain? > > Regards > Jaya > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] >
Client authentication using Certificate chain.
Hi All, If client authentication requested by the server, is it MUST to send the certificate chain along with client certificate? Does RFC mandates sending certificate chain? Regards Jaya __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
s_server with client authentication strange behaviour
Hi! I have found that when I run openssl s_server with client authentication: ./openssl s_server -accept 443 -cert m.cer -key mkey.pem -no_dhe -www -CAfile ca.cer -tls1 -verify 1 & and then without -verify 1, I see that transmission time are the same (I use Ethereal). How can it be explained? Does s_server simulate certificate checking? Any help will be appreciated. Best regards, Koza -- View this message in context: http://www.nabble.com/s_server-with-client-authentication-strange-behaviour-tp14708069p14708069.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 [EMAIL PROTECTED]
NEVER MIND - Re: Can't get PKI Client Authentication Enforcement to work
I believe I have solved the problem which was caused by some directory permissions. That is why when I ran openssl verify by hand, everything seemed to work. What threw me was Apache said it was reading the CA certs in the log, but apparently wasn't really. I spent 3 days working on this before posting to this mailing list, and a few hours after doing so, seem to have solved the problem. Sorry to have bothered everyone but maybe if someone else has the same problem in the future, they will find this and give their directory permissions a check. Quoting Joseph Felten <[EMAIL PROTECTED]>: > I'm stumped so I thought I would give this list a try as I believe my problem > is > an openssl issue. > > Background: Building an SSL enabled Apache web server on a closed network. > Apache under Solaris 8 OS. Need to restrict access to users with ID > certificates issued by particular CA's (issued by particular Root issuers) > read > from a smart card. I can make everything work except restricting access to > particular CA's. Whenever I enable SSLVerifyClient and SSLVerifyDepth in > Apache it denies all access even though I present a cert that was issued by > one > of the CA's under SSLCACertificatePath. Even though I have those CA's certs > loaded on the server and can dump and verify them with openssl. I get errors > in the Apache log such as.: > > "Certificate Verification: Error (20): unable to get local issuer > certificate" > > and > > "SSL Library Error: 336105650 error:140890B2:SSL > routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned" > > I'm not sure which certificate is not being returned. From the browser/smart > card? It seems to be presenting the cert to the server. I suspect that > error > is misleading. > > I know the browser is reading the cert from the smart card as the browser > security module kicks in and asks which cert from the smart card to present > to > the server. I can't just install the user ID cert directly in the browser as > they are flagged non-exportable for security reasons, plus the smart cards > are > a requirement. > > Software: Apache/2.2.4 (Unix) mod_jk/1.2.21 DAV/2 mod_ssl/2.2.4 > OpenSSL/0.9.8e > mod_perl/2.0.3 Perl/v5.8.8 > > I tried some tests with openssl verify, s_client, s_server etc. openssl > s_server seems happy with everything. For example.: > > openssl s_server -key conf/euukmoappd003n.dev.local.server.key -cert > conf/cert.euukmoappd003n.dev.local.server.crt -CApath conf/ssl.crt -state > -Verify 10 > > verify depth is 10, must return a certificate > Enter pass phrase for conf/disa.euukmoappd003n.dev.local.server.key: > Using default temp DH parameters > Using default temp ECDH parameters > ACCEPT > > And I can connect with s_client. > > Below is the debug log from starting the SSL server and trying and failing to > view a test page with a certificate issued by a root/CA chain the server has > loaded. When I try to load a test page, it grinds a bit, asks me to insert > my > smart card, grinds a bit, asks for my smart card PIN, grinds a bit more, then > the browser displays an error page that "The page cannot be displayed". This > is with microsoft internet explorer (unfortunately that is the browser the > users have). Sorry I can't post the actual certs here as we have pretty > tight > security rules. Thanks in advance. > > [Fri Dec 07 19:11:40 2007] [info] Loading certificate & private key of > SSL-aware > server > [Fri Dec 07 19:11:40 2007] [debug] ssl_engine_pphrase.c(481): encrypted RSA > private key - pass phrase reused > [Fri Dec 07 19:11:41 2007] [info] Configuring server for SSL protocol > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(405): Creating new SSL > context (protocols: SSLv3, TLSv1) > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(538): Configuring client > authentication > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: > /C=US/O=USG/OU=DD/OU=PKI/CN=DD CLASS 3 Root CA > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: > /C=US/O=USG/OU=ECA/CN=ECA Root CA > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: > /C=US/O=USG/OU=DD/OU=PKI/CN=DD Root CA 2 > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: > /C=US/ST=Cambs/L=Mole/O=USG/OU=USA OU PKI DD/CN=euukmoappd003n.dev.local > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: > /C=US/O=USG/OU=DD/OU=PKI/CN=DD CA-12 > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: > /C=US/O=USG/OU=DD/OU=PKI/CN=DD CLASS 3 Root CA > [Fri Dec 07 19:11:41 2007]
Follow up - Re: Can't get PKI Client Authentication Enforcement to work
Replying to my own message to add additional information. When I try it with Firefox, it asks which cert to use from my smart card etc. and then throws this error dialog.: "Could not establish an encrypted connection because your certificate was rejected by euukmoappd003n.dev.local. Error Code: -12271" I looked up Firefox error code -12271 = "SSL_ERROR_BAD_CERT_ALERT SSL peer cannot verify your certificate. The remote system has received a certificate from the local system, and has rejected it for some reason." Again, I have the proper CA's installed on the server including the one that issued the ID cert on the smart card. Quoting Joseph Felten <[EMAIL PROTECTED]>: > I'm stumped so I thought I would give this list a try as I believe my problem > is > an openssl issue. > > Background: Building an SSL enabled Apache web server on a closed network. > Apache under Solaris 8 OS. Need to restrict access to users with ID > certificates issued by particular CA's (issued by particular Root issuers) > read > from a smart card. I can make everything work except restricting access to > particular CA's. Whenever I enable SSLVerifyClient and SSLVerifyDepth in > Apache it denies all access even though I present a cert that was issued by > one > of the CA's under SSLCACertificatePath. Even though I have those CA's certs > loaded on the server and can dump and verify them with openssl. I get errors > in the Apache log such as.: > > "Certificate Verification: Error (20): unable to get local issuer > certificate" > > and > > "SSL Library Error: 336105650 error:140890B2:SSL > routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned" > > I'm not sure which certificate is not being returned. From the browser/smart > card? It seems to be presenting the cert to the server. I suspect that > error > is misleading. > > I know the browser is reading the cert from the smart card as the browser > security module kicks in and asks which cert from the smart card to present > to > the server. I can't just install the user ID cert directly in the browser as > they are flagged non-exportable for security reasons, plus the smart cards > are > a requirement. > > Software: Apache/2.2.4 (Unix) mod_jk/1.2.21 DAV/2 mod_ssl/2.2.4 > OpenSSL/0.9.8e > mod_perl/2.0.3 Perl/v5.8.8 > > I tried some tests with openssl verify, s_client, s_server etc. openssl > s_server seems happy with everything. For example.: > > openssl s_server -key conf/euukmoappd003n.dev.local.server.key -cert > conf/cert.euukmoappd003n.dev.local.server.crt -CApath conf/ssl.crt -state > -Verify 10 > > verify depth is 10, must return a certificate > Enter pass phrase for conf/disa.euukmoappd003n.dev.local.server.key: > Using default temp DH parameters > Using default temp ECDH parameters > ACCEPT > > And I can connect with s_client. > > Below is the debug log from starting the SSL server and trying and failing to > view a test page with a certificate issued by a root/CA chain the server has > loaded. When I try to load a test page, it grinds a bit, asks me to insert > my > smart card, grinds a bit, asks for my smart card PIN, grinds a bit more, then > the browser displays an error page that "The page cannot be displayed". This > is with microsoft internet explorer (unfortunately that is the browser the > users have). Sorry I can't post the actual certs here as we have pretty > tight > security rules. Thanks in advance. > > [Fri Dec 07 19:11:40 2007] [info] Loading certificate & private key of > SSL-aware > server > [Fri Dec 07 19:11:40 2007] [debug] ssl_engine_pphrase.c(481): encrypted RSA > private key - pass phrase reused > [Fri Dec 07 19:11:41 2007] [info] Configuring server for SSL protocol > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(405): Creating new SSL > context (protocols: SSLv3, TLSv1) > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(538): Configuring client > authentication > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: > /C=US/O=USG/OU=DD/OU=PKI/CN=DD CLASS 3 Root CA > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: > /C=US/O=USG/OU=ECA/CN=ECA Root CA > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: > /C=US/O=USG/OU=DD/OU=PKI/CN=DD Root CA 2 > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: > /C=US/ST=Cambs/L=Mole/O=USG/OU=USA OU PKI DD/CN=euukmoappd003n.dev.local > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: > /C=US/O=USG/OU=DD/OU=PKI/CN=DD CA-12 > [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certif
Can't get PKI Client Authentication Enforcement to work
I'm stumped so I thought I would give this list a try as I believe my problem is an openssl issue. Background: Building an SSL enabled Apache web server on a closed network. Apache under Solaris 8 OS. Need to restrict access to users with ID certificates issued by particular CA's (issued by particular Root issuers) read from a smart card. I can make everything work except restricting access to particular CA's. Whenever I enable SSLVerifyClient and SSLVerifyDepth in Apache it denies all access even though I present a cert that was issued by one of the CA's under SSLCACertificatePath. Even though I have those CA's certs loaded on the server and can dump and verify them with openssl. I get errors in the Apache log such as.: "Certificate Verification: Error (20): unable to get local issuer certificate" and "SSL Library Error: 336105650 error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned" I'm not sure which certificate is not being returned. From the browser/smart card? It seems to be presenting the cert to the server. I suspect that error is misleading. I know the browser is reading the cert from the smart card as the browser security module kicks in and asks which cert from the smart card to present to the server. I can't just install the user ID cert directly in the browser as they are flagged non-exportable for security reasons, plus the smart cards are a requirement. Software: Apache/2.2.4 (Unix) mod_jk/1.2.21 DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e mod_perl/2.0.3 Perl/v5.8.8 I tried some tests with openssl verify, s_client, s_server etc. openssl s_server seems happy with everything. For example.: openssl s_server -key conf/euukmoappd003n.dev.local.server.key -cert conf/cert.euukmoappd003n.dev.local.server.crt -CApath conf/ssl.crt -state -Verify 10 verify depth is 10, must return a certificate Enter pass phrase for conf/disa.euukmoappd003n.dev.local.server.key: Using default temp DH parameters Using default temp ECDH parameters ACCEPT And I can connect with s_client. Below is the debug log from starting the SSL server and trying and failing to view a test page with a certificate issued by a root/CA chain the server has loaded. When I try to load a test page, it grinds a bit, asks me to insert my smart card, grinds a bit, asks for my smart card PIN, grinds a bit more, then the browser displays an error page that "The page cannot be displayed". This is with microsoft internet explorer (unfortunately that is the browser the users have). Sorry I can't post the actual certs here as we have pretty tight security rules. Thanks in advance. [Fri Dec 07 19:11:40 2007] [info] Loading certificate & private key of SSL-aware server [Fri Dec 07 19:11:40 2007] [debug] ssl_engine_pphrase.c(481): encrypted RSA private key - pass phrase reused [Fri Dec 07 19:11:41 2007] [info] Configuring server for SSL protocol [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(405): Creating new SSL context (protocols: SSLv3, TLSv1) [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(538): Configuring client authentication [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=DD/OU=PKI/CN=DD CLASS 3 Root CA [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=ECA/CN=ECA Root CA [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=DD/OU=PKI/CN=DD Root CA 2 [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/ST=Cambs/L=Mole/O=USG/OU=USA OU PKI DD/CN=euukmoappd003n.dev.local [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=DD/OU=PKI/CN=DD CA-12 [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=DD/OU=PKI/CN=DD CLASS 3 Root CA [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=DD/OU=PKI/CN=DD CA-13 [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=ECA/CN=ECA Root CA [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=DD/OU=PKI/CN=DD CA-12 [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=DD/OU=PKI/CN=DD CA-13 [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=DD/OU=PKI/CN=DD CLASS 3 Root CA [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=DD/OU=PKI/CN=DD Root CA 2 [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=ECA/CN=ECA Root CA [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=DD/OU=PKI/CN=DD CA-12 [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(1113): CA certificate: /C=US/O=USG/OU=DD/OU=PKI/CN=DD Root CA 2 [Fri Dec 07 19:11:41 2007] [debug] ssl_engine_init.c(111
Re: SSL based client authentication
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Snuggles wrote:
> Hi,
Hello Snuggles,
> I'm writing my own webserver and I want it to be able to do SSL based client
> authentication. It can already do HTTPS, but when I try to do the SSL based
> client authentication, the connection gets dropped. I use the following
> routine to bind a SSL socket.
>
> SSL_CTX *ssl_binding(char *keyfile, char *CA_cert, int verify_depth, char
> *dh_file, char *ciphers) {
[...]
> if (CA_cert != NULL) {
> SSL_CTX_load_verify_locations(context, CA_cert, NULL);
You have to do a
SSL_CTX_set_client_CA_list(context,
SSL_load_client_CA_file(CA_cert));
> SSL_CTX_set_verify_depth(context, verify_depth);
> SSL_CTX_set_verify(context, SSL_VERIFY_PEER |
> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, 0);
[...]
> I hope anyone can tell what I am doing wrong or point me to some good
> documentation. Thanks!
see man page of SSL_CTX_set_client_CA_list()
Bye
Goetz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFF5X4J2iGqZUF3qPYRAl/AAJ94+D7tZRwtx7cjIv9UKlaqY6fOkACeKKgw
6hEJI2ZMvHqFlcp4N7l79RI=
=wXuj
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
SSL based client authentication
Hi,
I'm writing my own webserver and I want it to be able to do SSL based client
authentication. It can already do HTTPS, but when I try to do the SSL based
client authentication, the connection gets dropped. I use the following
routine to bind a SSL socket.
SSL_CTX *ssl_binding(char *keyfile, char *CA_cert, int verify_depth, char
*dh_file, char *ciphers) {
SSL_METHOD *meth;
SSL_CTX*context;
if ((meth = SSLv23_method()) == NULL) {
fprintf(stderr, "SSLv23_method() error\n");
return NULL;
}
if ((context = SSL_CTX_new(meth)) == NULL) {
fprintf(stderr, "SSL_CTX_new() error\n");
return NULL;
}
SSL_CTX_set_options(context, SSL_OP_NO_SSLv2);
if (SSL_CTX_use_certificate_chain_file(context, keyfile) != 1) {
fprintf(stderr, "Error while reading certificate from %s\n",
keyfile);
return NULL;
}
SSL_CTX_set_default_passwd_cb(context, sslPasswordCB);
if (SSL_CTX_use_PrivateKey_file(context, keyfile, SSL_FILETYPE_PEM) !=
1) {
fprintf(stderr, "Error while reading private key from %s\n",
keyfile);
return NULL;
}
if (CA_cert != NULL) {
SSL_CTX_load_verify_locations(context, CA_cert, NULL);
SSL_CTX_set_verify_depth(context, verify_depth);
SSL_CTX_set_verify(context, SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, 0);
}
if (dh_file != NULL) {
if (load_dh_params(context, dh_file) == -1) {
return NULL;
}
}
if (ciphers != NULL) {
if (SSL_CTX_set_cipher_list(context, ciphers) == 0) {
return NULL;
}
}
return context;
}
When CA_cert is NULL, no SSL client authentication is done, and everything
(HTTPS) works fine. But when I specify a CA certificate via CA_cert, I get a
"select certificate" window in IE6, but when I chose a certificate (it is a
valid one) the connection gives errors. Some of the HTTP content gets
through to the browser, some (like the pictures inside the HTML page) not.
The SSL_read() en SSL_write() give me (via SSL_get_error()) the
SSL_ERROR_SSL value. I've searched and googled, but I can't find anything
that looks like my problem.
I hope anyone can tell what I am doing wrong or point me to some good
documentation. Thanks!
P.S.
Sorry for the bad english :)
--
View this message in context:
http://www.nabble.com/SSL-based-client-authentication-tf3308555.html#a9203090
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 [EMAIL PROTECTED]
SSL based client authentication
Hi,
I'm writing my own webserver and I want it to be able to do SSL based client
authentication. It can already do HTTPS, but when I try to do the SSL based
client authentication, the connection gets dropped. I use the following
routine to bind a SSL socket.
SSL_CTX *ssl_binding(char *keyfile, char *CA_cert, int verify_depth, char
*dh_file, char *ciphers) {
SSL_METHOD *meth;
SSL_CTX*context;
if ((meth = SSLv23_method()) == NULL) {
fprintf(stderr, "SSLv23_method() error\n");
return NULL;
}
if ((context = SSL_CTX_new(meth)) == NULL) {
fprintf(stderr, "SSL_CTX_new() error\n");
return NULL;
}
SSL_CTX_set_options(context, SSL_OP_NO_SSLv2);
if (SSL_CTX_use_certificate_chain_file(context, keyfile) != 1) {
fprintf(stderr, "Error while reading certificate from %s\n",
keyfile);
return NULL;
}
SSL_CTX_set_default_passwd_cb(context, sslPasswordCB);
if (SSL_CTX_use_PrivateKey_file(context, keyfile, SSL_FILETYPE_PEM) !=
1) {
fprintf(stderr, "Error while reading private key from %s\n",
keyfile);
return NULL;
}
if (CA_cert != NULL) {
SSL_CTX_load_verify_locations(context, CA_cert, NULL);
SSL_CTX_set_verify_depth(context, verify_depth);
SSL_CTX_set_verify(context, SSL_VERIFY_PEER |
SSL_VERIFY_FAIL_IF_NO_PEER_CERT, 0);
}
if (dh_file != NULL) {
if (load_dh_params(context, dh_file) == -1) {
return NULL;
}
}
if (ciphers != NULL) {
if (SSL_CTX_set_cipher_list(context, ciphers) == 0) {
return NULL;
}
}
return context;
}
When CA_cert is NULL, no SSL client authentication is done, and everything
(HTTPS) works fine. But when I specify a CA certificate via CA_cert, I get a
"select certificate" window in IE6, but when I chose a certificate (it is a
valid one) the connection gives errors. Some of the HTTP content gets
through to the browser, some (like the pictures inside the HTML page) not.
The SSL_read() en SSL_write() give me (via SSL_get_error()) the
SSL_ERROR_SSL value. I've searched and googled, but I can't find anything
that looks like my problem.
I hope anyone can tell what I am doing wrong or point me to some good
documentation. Thanks!
P.S.
Sorry for the bad english :)
--
View this message in context:
http://www.nabble.com/SSL-based-client-authentication-tf3169307.html#a8791684
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 [EMAIL PROTECTED]
Re: Problems with s_client - client-authentication on command line
Hello, > I'm trying to automate a test against a server with client authentication. > I created a self signed certificate, put it into the servers key database and > imported it into a browsers key store (e.g. M$IE cert store). Everything's > fine > - I'm able to sign on against the server. > > So far, so good... > > Unfortunately with OpenSSL-CLI (0.9.7j) I'm only getting errors: > > openssl s_client -key mycert.pem -cert suntest07.cer -connect suntest07:460 > > unable to get private key from 'mycert.pem' > 27461:error:0B080074:x509 certificate routines:X509_check_private_key:key > values > mismatch:x509_cmp.c:411 > > > suntest07.cer contains the (also selfsigned) x.509-Cert of the server, > mycert.pem contains my private key and certificate. Private key is read from file specified with -key option (but not cert), key certificate is read from file with -cert option (and private key if -key not specified). After that public part of private key is checked with signed public part of certificate from -cert file - they must match. In this case public part of private key from mycert.pem do not match public part of certificate from suntest07.cer. Probably, you do something like: openssl s_client -cert mycert.pem -connect suntest07:460 and this should work (provided that mycert.pem has private key and certificate). Best regards, -- Marek Marcola <[EMAIL PROTECTED]> __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Problems with s_client - client-authentication on command line
Hi all, I'm trying to automate a test against a server with client authentication. I created a self signed certificate, put it into the servers key database and imported it into a browsers key store (e.g. M$IE cert store). Everything's fine - I'm able to sign on against the server. So far, so good... Unfortunately with OpenSSL-CLI (0.9.7j) I'm only getting errors: openssl s_client -key mycert.pem -cert suntest07.cer -connect suntest07:460 unable to get private key from 'mycert.pem' 27461:error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch:x509_cmp.c:411 suntest07.cer contains the (also selfsigned) x.509-Cert of the server, mycert.pem contains my private key and certificate. I'm quit sure, that it can only be a little problem... Any hints? TIA and regards, Sebastian __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
client authentication - error message included
Thanks for ur response.. the error messages of client and server are follows.. client : error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1052:SSL alert number 48 server: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned : s3_srvr.c:2015 in my s_client call i correctly specified the CAfile path. S_client -connect ip:port -cert clientcert.pem -key clientPrivKey.pem -CAfile /../../demoCA/cacert.pem so is the client not able to locate the CAfile ..? if yes i wonder why? Do I need to explicitly define somewhere in my server program that this CA is trusted..? Awaiting for the suggestions
Re: problem in client authentication -no luck
Samy Thiyagarajan wrote: hi .. now i created a CA and a certificate signed by it. my client call is now, s_client -connect ip:port -cert clientcert.pem -key clientPrivKey.pem -CAfile cakey.pem still no development can someone look into this issue please...? The CAfile for tjhe openssl s_client command is used to authenticate the SERVER. You need load the CA certificate in your server. Look at the source code of s_server.c etc smime.p7s Description: S/MIME Cryptographic Signature
RE: problem in client authentication -no luck
You don't want to specify the CA's private key as the argument for -CAfile, you need to specify the CA certificate for that. Also an indication of the errors you get would help ... D. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Samy Thiyagarajan Sent: 10 January 2006 14:53 To: openssl-users@openssl.org Subject: problem in client authentication -no luck hi .. now i created a CA and a certificate signed by it. my client call is now, s_client -connect ip:port -cert clientcert.pem -key clientPrivKey.pem -CAfile cakey.pem still no development can someone look into this issue please...? "Mark" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10.01.2006 14:12 Please respond to openssl-users@openssl.org To openssl-users@openssl.org cc Subject RE: problem in client authentication Classification > my last mail seem to be lost somewhere.. I got it! > Hi all, > > Im testing an SSL server with s_client. I want to implement > client authentication. > > The problem is even if I include the certificate and key file > in my client call, SSL_get_peer_certificate() > returns NULL > > I tried the following calls, > > a) S_client -connect ip:port > b) s_client -connect ip:port -cert clientcert.pem -key > clientPrivkey.pem I would think you would need to specify the root certificate using the -CAfile option. Cheers, Mark __ 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]
problem in client authentication -no luck
hi .. now i created a CA and a certificate signed by it. my client call is now, s_client -connect ip:port -cert clientcert.pem -key clientPrivKey.pem -CAfile cakey.pem still no development can someone look into this issue please...? "Mark" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 10.01.2006 14:12 Please respond to openssl-users@openssl.org To openssl-users@openssl.org cc Subject RE: problem in client authentication Classification > my last mail seem to be lost somewhere.. I got it! > Hi all, > > Im testing an SSL server with s_client. I want to implement > client authentication. > > The problem is even if I include the certificate and key file > in my client call, SSL_get_peer_certificate() > returns NULL > > I tried the following calls, > > a) S_client -connect ip:port > b) s_client -connect ip:port -cert clientcert.pem -key > clientPrivkey.pem I would think you would need to specify the root certificate using the -CAfile option. Cheers, Mark __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: problem in client authentication
> my last mail seem to be lost somewhere.. I got it! > Hi all, > > Im testing an SSL server with s_client. I want to implement > client authentication. > > The problem is even if I include the certificate and key file > in my client call, SSL_get_peer_certificate() > returns NULL > > I tried the following calls, > > a) S_client -connect ip:port > b) s_client -connect ip:port -cert clientcert.pem -key > clientPrivkey.pem I would think you would need to specify the root certificate using the -CAfile option. Cheers, Mark __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
problem in client authentication
my last mail seem to be lost somewhere..
Hi all,
Im testing an SSL server with s_client.
I want to implement client authentication.
The problem is even if I include the
certificate and key file in my client call, SSL_get_peer_certificate()
returns NULL
I tried the following calls,
a) S_client -connect ip:port
b) s_client -connect ip:port -cert clientcert.pem
-key clientPrivkey.pem
** the certificate is self signed.
here is the piece of code of my server..
SSL_CTX_set_verify( ctx, SSL_VERIFY_PEER
| SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL );
SSL_accept();
//SSL_accept is successful
X509 *peer;
peer = SSL_get_peer_certificate( ssl
);
if( peer == NULL )
{
errorexit( " cannot
get the certificate " );
}
else
{
if( SSL_get_verify_result(
ssl ) == X509_V_OK )
{
printf( "
certificate OK " );
// do read
and write..
}
}
Irrespective of my s_client call
( a or b ) I get the error " cannot get the certificate"
Am I missing something?
Expecting your valuable suggestions..
Thanks in advance.
-Samy
problem in client authentication
Hi all,
Im testing an SSL server with s_client.
I want to implement client authentication.
The problem is even if I include the
certificate and key file in my client call, SSL_get_peer_certificate()
returns NULL
I tried the following calls,
a) S_client -connect ip:port
b) s_client -connect ip:port -cert clientcert.pem
-key clientPrivkey.pem
** the certificate is self signed.
here is the piece of code of my server..
SSL_CTX_set_verify( ctx, SSL_VERIFY_PEER
| SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL );
SSL_accept();
//SSL_accept is successful
X509 *peer;
peer = SSL_get_peer_certificate( ssl
);
if( peer == NULL )
{
errorexit( " cannot
get the certificate " );
}
else
{
if( SSL_get_verify_result(
ssl ) == X509_V_OK )
{
printf( "
certificate OK " );
// do read
and write..
}
}
Irrespective of my s_client call
( a or b ) I get the error " cannot get the certificate"
Am I missing something?
Expecting your valuable suggestions..
Thanks in advance.
-Samy
RE: Enable Client Authentication using [ Openssl s_server ]
Try using one of these two -verify arg - turn on peer certificate verification -Verify arg - turn on peer certificate verification, must have a cert. in the command, btw u can get the whole list of options in man s_server -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of am0ykam0te (sent by Nabble.com) Sent: Thursday, December 08, 2005 10:42 AM To: openssl-users@openssl.org Subject: Enable Client Authentication using [ Openssl s_server ] I am currently testing the ssl client i developed. I need to test it when it connects to a server which requires client authentication. However i do not know how to enable it in openssl's command line server (s_server). How do i enable client authentication in openssl s_server? Sent from the OpenSSL - User forum at Nabble.com: Enable Client Authentication using [ Openssl s_server ] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Enable Client Authentication using [ Openssl s_server ]
I am currently testing the ssl client i developed. I need to test it when it connects to a server which requires client authentication. However i do not know how to enable it in openssl's command line server (s_server). How do i enable client authentication in openssl s_server? Sent from the OpenSSL - User forum at Nabble.com: Enable Client Authentication using [ Openssl s_server ]
Enable Client Authentication using [ Openssl s_server ]
I am currently testing the ssl client i developed. I need to test it when it connects to a server which requires client authentication. However i do not know how to enable it in openssl's command line server (s_server). How do i enable client authentication in openssl s_server? Sent from the OpenSSL - User forum at Nabble.com: Enable Client Authentication using [ Openssl s_server ]
Re: client authentication
Frans Gunawan wrote: Hello, How to test client auth with the "openssl s_server" and "openssl s_client" to show that the authentication is using the client auth. Thank you, Frans Quoted from s_server-manpage (http://www.openssl.org/docs/apps/s_server.html): * **-verify depth*, *-Verify depth** The verify depth to use. This specifies the maximum length of the client certificate chain and makes the server request a certificate from the client. With the *-verify* option a certificate is requested but the client does not have to send one, with the *-Verify* option the client must supply a certificate or an error occurs. *So if you use this option on the server the client must authenticate. Is it this you were asking? Hope it helps. Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
client authentication
Hello,How to test client auth with the "openssl s_server" and "openssl s_client"to show that the authentication is using the client auth. Thank you,Frans
Re: Client authentication problem
Hey can you try setting verify depth to Zero and not pointing to any CA cert i.e SSLCACertificatePath pointing to null? Thanks --Gayathri > Hi Again., > > This is what I found from the "log" file you sent..is this pointing to the > same CA cert "itcilo-ca.crt, I put it in ssl.crt" ? > > debug] ssl_engine_init.c(1112): CA certificate: > /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO > CA/[EMAIL PROTECTED] > [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_init.c(703): Configuring > server certificate chain (1 CA certificate) > > You will not find that option "SSL_VERIFY_FAIL_IF_NO_PEER_CERT" thats > openssl macro..I thought you had written your own server.. > > found this link > http://httpd.apache.org/docs-2.0/mod/mod_ssl.html > perhaps your already aware of this..but sorry no idea abt apache mod ssl > :) > > Thanks > Gayathri > > > >> Hi. > > Hi, > > Thanks for the reply > >> Have you imported the CA of the client cert on the server side? > > Yes, it's the itcilo-ca.crt, I put it in ssl.crt (self-signed) > >> A verify depth of 1 has been set, which could mean that the client >> cert is self signed? Can you set it to some higher value and try? > > Yes, it's a self signed certificate, I tried with a higher values (5) > without any success > >> Also can you check whether the option "SSL_VERIFY_FAIL_IF_NO_PEER_CERT"? > > I searched for the string on my server but can not find it. In which > should I find it? > >> Can you retry the same thing from Mozilla or something. > > I tried with firefox with the same result > >> is your server mod_ssl? > > Yes, apache 2 on suse includes it by default. > > I turned the loglevel to debug and attached the log file below, just in > case > > There are a lot of > Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1793): OpenSSL: > Handshake: start > [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: > Loop: before/accept initialization > [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_io.c(1518): OpenSSL: I/O > error, 11 bytes expected to read on BIO#836ffc8 [mem: 8377648] > [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1830): OpenSSL: > Exit: error in SSLv2/v3 read client hello A > [Wed Jul 13 11:48:34 2005] [info] (70014)End of file found: SSL > handshake interrupted by system [Hint: Stop button pressed in > browser?!] > [Wed Jul 13 11:48:34 2005] [info] Connection to child 9 closed with > abortive shutdown(server tomcat-ssl.itcilo.org:443, client ::1) > [Wed Jul 13 11:48:34 2005] [info] Connection to child 9 established > (server tomcat-ssl.itcilo.org:443, client ::1) > [Wed Jul 13 11:48:34 2005] [info] Seeding PRNG with 136 bytes of entropy > > and then > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1793): OpenSSL: > Handshake: start > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: > Loop: before/accept initialization > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1507): OpenSSL: > read 11/11 bytes from BIO#8372060 [mem: 83776d8] (BIO dump follows) > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1454): > +-+ > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | : 80 > 67 01 03 00 00 4e 00-00 00 10 .gN | > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1485): > +-+ > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1507): OpenSSL: > read 94/94 bytes from BIO#8372060 [mem: 83776e3] (BIO dump follows) > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1454): > +-+ > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | : 01 > 00 80 03 00 80 07 00-c0 06 00 40 02 00 80 04 [EMAIL PROTECTED] | > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0010: 00 > 80 00 00 39 00 00 38-00 00 35 00 00 33 00 00 9..8..5..3.. | > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0020: 32 > 00 00 04 00 00 05 00-00 2f 00 00 16 00 00 13 2/.. | > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0030: 00 > fe ff 00 00 0a 00 00-15 00 00 12 00 fe fe 00 | > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0040: 00 > 09 00 00 64 00 00 62-00 00 03 00 00 06 69 13 d..b..i. | > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0050: 73 > ff 86 72 4e 7d 52 4a-fe 9a b9 38 b9 1es..rN}RJ...8.. | > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1485): > +-+ > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: > Loop: SSLv3 read client hello A > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: > Loop: SSLv3 write server hello A > [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: > Loop: SSLv3 write certificate A > [Wed Ju
Re: Client authentication problem
Hi Again., This is what I found from the "log" file you sent..is this pointing to the same CA cert "itcilo-ca.crt, I put it in ssl.crt" ? debug] ssl_engine_init.c(1112): CA certificate: /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO CA/[EMAIL PROTECTED] [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_init.c(703): Configuring server certificate chain (1 CA certificate) You will not find that option "SSL_VERIFY_FAIL_IF_NO_PEER_CERT" thats openssl macro..I thought you had written your own server.. found this link http://httpd.apache.org/docs-2.0/mod/mod_ssl.html perhaps your already aware of this..but sorry no idea abt apache mod ssl :) Thanks Gayathri > Hi. Hi, Thanks for the reply > Have you imported the CA of the client cert on the server side? Yes, it's the itcilo-ca.crt, I put it in ssl.crt (self-signed) > A verify depth of 1 has been set, which could mean that the client > cert is self signed? Can you set it to some higher value and try? Yes, it's a self signed certificate, I tried with a higher values (5) without any success > Also can you check whether the option "SSL_VERIFY_FAIL_IF_NO_PEER_CERT"? I searched for the string on my server but can not find it. In which should I find it? > Can you retry the same thing from Mozilla or something. I tried with firefox with the same result > is your server mod_ssl? Yes, apache 2 on suse includes it by default. I turned the loglevel to debug and attached the log file below, just in case There are a lot of Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1793): OpenSSL: Handshake: start [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: before/accept initialization [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_io.c(1518): OpenSSL: I/O error, 11 bytes expected to read on BIO#836ffc8 [mem: 8377648] [Wed Jul 13 11:48:34 2005] [debug] ssl_engine_kernel.c(1830): OpenSSL: Exit: error in SSLv2/v3 read client hello A [Wed Jul 13 11:48:34 2005] [info] (70014)End of file found: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!] [Wed Jul 13 11:48:34 2005] [info] Connection to child 9 closed with abortive shutdown(server tomcat-ssl.itcilo.org:443, client ::1) [Wed Jul 13 11:48:34 2005] [info] Connection to child 9 established (server tomcat-ssl.itcilo.org:443, client ::1) [Wed Jul 13 11:48:34 2005] [info] Seeding PRNG with 136 bytes of entropy and then [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1793): OpenSSL: Handshake: start [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: before/accept initialization [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1507): OpenSSL: read 11/11 bytes from BIO#8372060 [mem: 83776d8] (BIO dump follows) [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1454): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | : 80 67 01 03 00 00 4e 00-00 00 10 .gN | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1485): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1507): OpenSSL: read 94/94 bytes from BIO#8372060 [mem: 83776e3] (BIO dump follows) [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1454): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | : 01 00 80 03 00 80 07 00-c0 06 00 40 02 00 80 04 [EMAIL PROTECTED] | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0010: 00 80 00 00 39 00 00 38-00 00 35 00 00 33 00 00 9..8..5..3.. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0020: 32 00 00 04 00 00 05 00-00 2f 00 00 16 00 00 13 2/.. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0030: 00 fe ff 00 00 0a 00 00-15 00 00 12 00 fe fe 00 | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0040: 00 09 00 00 64 00 00 62-00 00 03 00 00 06 69 13 d..b..i. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1479): | 0050: 73 ff 86 72 4e 7d 52 4a-fe 9a b9 38 b9 1es..rN}RJ...8.. | [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_io.c(1485): +-+ [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 read client hello A [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 write server hello A [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 write certificate A [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1185): handing out temporary 1024 bit DH key [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 write key exchange A [Wed Jul 13 11:48:42 2005] [debug] ssl_engine_kernel.c(1801): OpenSSL: Loop: SSLv3 write certificate request A [Wed Jul 13 11:48:42 2005]
Re: Client authentication problem
Hi. Have you imported the CA of the client cert on the server side? A verify depth of 1 has been set, which could mean that the client cert is self signed? Can you set it to some higher value and try? Also can you check whether the option "SSL_VERIFY_FAIL_IF_NO_PEER_CERT"? It looks to me a definitive server side issue.. Can you retry the same thing from Mozilla or something. FYI: I implemented the exacy same thing recently and didnt see such problems..is your server mod_ssl? Thanks --Gayathri > The above indicates that. Make sure client cert > processing is done correctly on the server side. If it > is a program failure, then you need to get the > programmer to debug the program. > Thank you for your answer. I'm not sure what you intend with "program failure": the pages served by this virtual host are for the time being only static html pages. The only programs involed are apache, openssl and the browser I tried the following command found in the openssl faq "openssl s_client -connect tomcat-ssl.itcilo.org:443 -state -debug" and it finished with the following error: SSL_connect:SSLv3 write client key exchange A write to 080B07A0 [080BFFC0] (6 bytes => -1 (0x)) SSL_connect:error in SSLv3 write finished A SSL_connect:error in SSLv3 write finished A I've googled a little bit but didn't really find something that allowed me to solve my problem. host:~/CA # openssl s_client -connect myhost:443 -showcerts -CAfile /root/CA/itcilo-ca.crt CONNECTED(0003) depth=1 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO CA/[EMAIL PROTECTED] verify return:1 depth=0 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=myhost/[EMAIL PROTECTED] verify return:1 17680:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1052:SSL alert number 40 17680:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226: I also tried passing to "openssl s_client" the client certificate and key, with also an error, as you can see below: dolphin:~/CA # openssl s_client -cert lams.crt -key lams.key -CAfile itcilo-ca.crt -ssl3 -showcerts -connect myhost:443 CONNECTED(0003) depth=1 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO CA/[EMAIL PROTECTED] verify return:1 depth=0 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=myhost/[EMAIL PROTECTED] verify return:1 17910:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:529: I tried with ssl2 with same exit. I'm searching but really don't understand the problem. I also created again all the certificates with the same result. Any help would be appreciated as I'm pretty baffled Regards, Gaël __ 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: Client authentication problem
> The above indicates that. Make sure client cert > processing is done correctly on the server side. If it > is a program failure, then you need to get the > programmer to debug the program. > Thank you for your answer. I'm not sure what you intend with "program failure": the pages served by this virtual host are for the time being only static html pages. The only programs involed are apache, openssl and the browser I tried the following command found in the openssl faq "openssl s_client -connect tomcat-ssl.itcilo.org:443 -state -debug" and it finished with the following error: SSL_connect:SSLv3 write client key exchange A write to 080B07A0 [080BFFC0] (6 bytes => -1 (0x)) SSL_connect:error in SSLv3 write finished A SSL_connect:error in SSLv3 write finished A I've googled a little bit but didn't really find something that allowed me to solve my problem. host:~/CA # openssl s_client -connect myhost:443 -showcerts -CAfile /root/CA/itcilo-ca.crt CONNECTED(0003) depth=1 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO CA/[EMAIL PROTECTED] verify return:1 depth=0 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=myhost/[EMAIL PROTECTED] verify return:1 17680:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1052:SSL alert number 40 17680:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226: I also tried passing to "openssl s_client" the client certificate and key, with also an error, as you can see below: dolphin:~/CA # openssl s_client -cert lams.crt -key lams.key -CAfile itcilo-ca.crt -ssl3 -showcerts -connect myhost:443 CONNECTED(0003) depth=1 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=ITCILO CA/[EMAIL PROTECTED] verify return:1 depth=0 /C=IT/ST=Piemonte/L=Turin/O=ITCILO/OU=MIS/CN=myhost/[EMAIL PROTECTED] verify return:1 17910:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:529: I tried with ssl2 with same exit. I'm searching but really don't understand the problem. I also created again all the certificates with the same result. Any help would be appreciated as I'm pretty baffled Regards, Gaël __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client authentication problem
Looks to me that client authentication failed. And this is most likely due to client cert processing on the server side: [notice] child pid 9192 exit signal Segmentation fault (11) The above indicates that. Make sure client cert processing is done correctly on the server side. If it is a program failure, then you need to get the programmer to debug the program. Regards, Dr. Wu --- Gaël Lams <[EMAIL PROTECTED]> wrote: > Hi all, > > I'm trying to configure client authentication for > one of my sites > (SuSe 9.0, apache 2.0.48, openssl-0.9.7b-133 > distribution's rpm). > You will find below the steps I'm following, the > problem I have is > that, when I go to the page, it first asks me to > accept the server's > certificate, then ask me to select one of the client > certificate > imported in the browser, and then: > - on IE, it gives me the error "Cannot find server > or DNS Error" > - on Firefox, it gives me a blank page > > In the apache log file > [Tue Jul 12 15:03:41 2005] [error] Re-negotiation > handshake failed: > Not accepted by client!? > [Tue Jul 12 15:03:43 2005] [notice] child pid 9192 > exit signal > Segmentation fault (11) > > If I remove "SSLVerifyCLient require" and > authenticate only the > server, I can see the right web page. > > After several unsuccessful test, I'm wondering > whether I'm missing something > > Here are the steps I follow: > > 1 Generate my own Certificate Authority: > > openssl genrsa -out itcilo-ca.key 2048 > openssl req -new -x509 -days 3650 -key itcilo-ca.key > -out itcilo-ca.crt > > 2 Generate the server key and request for signing > > openssl genrsa -out tomcat-server.key 1024 > openssl req -new -key tomcat-server.key -out > tomcat-server.csr > > 3 Sign the certificate signing request with the > self-created > certificate authority > > openssl x509 -req -in tomcat-server.csr -out > tomcat-server.crt -sha1 > -CA itcilo-ca.crt -CAkey itcilo-ca.key -days 3650 > > I had to create an itcilo-ca.srl file (echo "01" > >itcilo-ca.srl) > > 4 Create a new private key and a certificate request > for the user: > openssl genrsa -out lams.key 1024 > openssl req -new -key lams.key -out lams.csr > > 5 Sign the certificate request, thereby creating the > client certificate: > openssl x509 -req -in lams.csr -out lams.crt -sha1 > -CA itcilo-ca.crt > -CAkey itcilo-ca.key -days 3650 > > 6 Generate the PKCS#12 certificate: > openssl pkcs12 -export -in lams.crt -inkey lams.key > -name "Lams Gael > Cert" -out lams.p12 > > 7 Import the certificate into the browser > > And here is my virtual host configuration: > > ServerAdmin myemailaddress > DocumentRoot /srv/www/vhosts/myfqdn > ServerName myfqdn > SSLEngine on > SSLCertificateFile > /etc/apache2/ssl.crt/tomcat-server.crt > SSLCertificateKeyFile > /etc/apache2/ssl.key/tomcat-server.key > SSLCACertificateFile > /etc/apache2/ssl.crt/itcilo-ca.crt > > > > > > SSLRequireSSL > SSLVerifyCLient require > SSLVerifyDepth 1 > > Options Indexes > AllowOverride None > Order allow,deny > Allow from all > > > > Any help, pointer would be greatly appreciated > > Regards, > > gaël > __ > OpenSSL Project > http://www.openssl.org > User Support Mailing List > openssl-users@openssl.org > Automated List Manager > [EMAIL PROTECTED] > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Client authentication problem
Hi all, I'm trying to configure client authentication for one of my sites (SuSe 9.0, apache 2.0.48, openssl-0.9.7b-133 distribution's rpm). You will find below the steps I'm following, the problem I have is that, when I go to the page, it first asks me to accept the server's certificate, then ask me to select one of the client certificate imported in the browser, and then: - on IE, it gives me the error "Cannot find server or DNS Error" - on Firefox, it gives me a blank page In the apache log file [Tue Jul 12 15:03:41 2005] [error] Re-negotiation handshake failed: Not accepted by client!? [Tue Jul 12 15:03:43 2005] [notice] child pid 9192 exit signal Segmentation fault (11) If I remove "SSLVerifyCLient require" and authenticate only the server, I can see the right web page. After several unsuccessful test, I'm wondering whether I'm missing something Here are the steps I follow: 1 Generate my own Certificate Authority: openssl genrsa -out itcilo-ca.key 2048 openssl req -new -x509 -days 3650 -key itcilo-ca.key -out itcilo-ca.crt 2 Generate the server key and request for signing openssl genrsa -out tomcat-server.key 1024 openssl req -new -key tomcat-server.key -out tomcat-server.csr 3 Sign the certificate signing request with the self-created certificate authority openssl x509 -req -in tomcat-server.csr -out tomcat-server.crt -sha1 -CA itcilo-ca.crt -CAkey itcilo-ca.key -days 3650 I had to create an itcilo-ca.srl file (echo "01" >itcilo-ca.srl) 4 Create a new private key and a certificate request for the user: openssl genrsa -out lams.key 1024 openssl req -new -key lams.key -out lams.csr 5 Sign the certificate request, thereby creating the client certificate: openssl x509 -req -in lams.csr -out lams.crt -sha1 -CA itcilo-ca.crt -CAkey itcilo-ca.key -days 3650 6 Generate the PKCS#12 certificate: openssl pkcs12 -export -in lams.crt -inkey lams.key -name "Lams Gael Cert" -out lams.p12 7 Import the certificate into the browser And here is my virtual host configuration: ServerAdmin myemailaddress DocumentRoot /srv/www/vhosts/myfqdn ServerName myfqdn SSLEngine on SSLCertificateFile /etc/apache2/ssl.crt/tomcat-server.crt SSLCertificateKeyFile /etc/apache2/ssl.key/tomcat-server.key SSLCACertificateFile /etc/apache2/ssl.crt/itcilo-ca.crt SSLRequireSSL SSLVerifyCLient require SSLVerifyDepth 1 Options Indexes AllowOverride None Order allow,deny Allow from all Any help, pointer would be greatly appreciated Regards, gaël __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication
On the Mac, you'll load your client certificate into your users' keychains. On Windows, you'll load it into the certificate store. In either case, simply having the user double-click on the certificate file will launch the appropriate tool. On Apr 18, 2005, at 9:17 PM, [EMAIL PROTECTED] wrote: Hi Apart from Mac clients I also windows users. Regards and Thanks Mahesh S Kudva __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Client Authentication
Hi Apart from Mac clients I also windows users. Regards and Thanks Mahesh S Kudva __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication
This would be a feature of Safari rather than OpenSSL. I'm pretty sure that recent versions of Safari can do authentication using certs, but I'm not sure how to do it. You can try posting you question to one of Apple's lists. http://lists.apple.com/ On Apr 18, 2005, at 1:46 AM, [EMAIL PROTECTED] wrote: Hi all I am a newbie to SSL and I want to have clients authenticated using SSL certificates. I am running webserver on Apache 1.3 on Mac OS X server The scenario is something as follows: My webserver is hosting an site for which I want to give limited access worldwide. If someone requests for the site, the first check should be made using the certificates. If the certificate is not present in the clients machine, the "Access denied" page must pop up. The questions is how do I do client authentication Requesting your assistance. Regards & Thanks Mahesh S Kudva __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Client Authentication
Hi all I am a newbie to SSL and I want to have clients authenticated using SSL certificates. I am running webserver on Apache 1.3 on Mac OS X server The scenario is something as follows: My webserver is hosting an site for which I want to give limited access worldwide. If someone requests for the site, the first check should be made using the certificates. If the certificate is not present in the clients machine, the "Access denied" page must pop up. The questions is how do I do client authentication Requesting your assistance. Regards & Thanks Mahesh S Kudva __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Problem in Client authentication
Hi, I am creating a webservice in C++ using gSOAP 2.6.2 with OpenSSL-v0.9.7e. Client authentication is enabled. The first request works and command executes successfully, but the second request(and subsequent) fails with the following errors Client side SOAP FAULT: SOAP-ENV:Client "SSL_ERROR_SSL error:1409441B:SSL routines:SSL3_READ_BYTES:tlsv1 alert decrypt error" Detail: SSL connect failed in tcp_connect() Server side: SOAP FAULT: SOAP-ENV:Server "SSL_ERROR_SSL error:0D0890A1:lib(13):func(137):reason(161)error:140890B2:lib(20):func(137):reason(178)" Detail: SSL_accept() failed in soap_ssl_accept() Then onwards all the requests always fails till I restart my webservice. Can anyone help me on this? Regards, Manu __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication and Private Key
Intuitively, you have to know that the client needs it's private key for something. Since the public key certificate is public, it alone can't prove that the client is you. Anyone can send your certificate to a server, right? In practice, the server walks the certificate chain, which proves that the certificate is cryptographically valid. It then sends a challenge to the client, which the client signs with its private key. Once the server verifies the signature using the client public key, it knows that the client is you (only if it trusts the certificate chain.). > If the client sends the server its certificate (public key) and the > server validates the signature against the list of CA's to see if the > client is authenticated/valid then my question is... if the client is > not going to use the private key for signing does it even NEED the > primary key AT ALL? Can it be deleted? -- Ken Goldman [EMAIL PROTECTED] 914-784-7646 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication and Private Key
As I understand it, the client signs data sent from the server in order to authenticate itself. Therefore yes it does need its private key. On Tue, 18 Jan 2005 11:17:01 +, Shaun Lipscombe <[EMAIL PROTECTED]> wrote: > > If the client sends the server its certificate (public key) and the > server validates the signature against the list of CA's to see if the > client is authenticated/valid then my question is... if the client is > not going to use the private key for signing does it even NEED the > primary key AT ALL? Can it be deleted? > __ > 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]
SSL Client Authentication using p12 File
HI, I have a p12 file that I need to use for authenticating myself as a client to access a secured site. I am talking about Trans Union site. Has anyone done anything in this area ? How can this be done. Regards, Kushal. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
IE5 client authentication
Hi all, Is it possible for a Windows client using IE5.0 to authenticate itself in order to connect to a SSL server? My server works fine with many clients, but not with this one... The great tool ssldump dumps that: 18 5 0.1324 (0.0295) C>SV3.0(273) Handshake Certificate ClientKeyExchange EncryptedPreMasterSecret[128]= 8b f7 ee 95 2d 26 88 4e 61 ea af 29 b8 76 ed 1b 86 d2 97 27 63 30 60 16 e3 b6 1c b8 5b 1c 9d 2f 68 19 68 7d 39 4f 60 9f 22 7a 72 06 56 b2 c5 18 6c 76 34 12 a3 75 4c e3 bb 05 d0 12 b0 62 b5 57 c4 f2 a0 c5 40 c0 aa d1 da dd e9 2e 25 90 35 c7 7f bf 61 c4 f3 e8 fa aa 9b ae 3d 9e 49 41 f7 2e CertificateVerify Signature[128]= 2a c6 6e 30 bb ba 47 25 3c 2f 69 28 13 3f 67 5f bf 9d d7 d8 0e 53 c1 18 64 e2 03 dc ce 74 28 3c 27 d4 5e 69 95 ab 5d 21 9f 17 e0 bd ff 62 25 70 d8 73 46 86 4f d8 30 d2 56 ca a0 7f 30 54 82 e3 d0 21 8a a2 e5 2a 0c 93 cf d7 7c 2b 10 94 34 92 bf 79 20 5c bc 9a 5d 61 fe f2 26 46 fc 50 e9 02 2d 7f 92 ba db 01 1a 96 6e 48 99 ba 71 e6 f3 1d 16 a0 2b 88 fa 1c eb b0 b7 a6 64 4a 4c ef b5 d1 18 6 0.1324 (0.) C>SV3.0(1) ChangeCipherSpec 18 7 0.1324 (0.) C>SV3.0(60) Handshake Finished md5_hash[16]= 95 d2 94 d4 e4 07 da 7f d7 35 7e 08 46 c8 06 9f sha_hash[20]= 6d a2 df aa ce d1 f5 9b ed 4b c9 c2 46 d5 7c 4d 7e d5 24 f5 18 8 0.1382 (0.0058) S>CV3.0(2) Alert level fatal value handshake_failure 180.1388 (0.0005) C>S TCP FIN 180.1446 (0.0058) S>C TCP FIN Thanks for reading me, and why not for answering me :) Alexis. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[C/C++] Client authentication not working
Hi everybody, i got a problem with the client authetication. Searching the web and the archive of this mailinglist did not help so i hope theres some expert around here who can. I got: - a demoCA with certificate an key - a certificate an key for the server - the same for the client The client is doing (i leave out the params): SSL_library_init(); SSL_load_error_strings(); ctx = SSL_CTX_new (SSLv3_client_method()); SSL_CTX_use_certificate_file(); SSL_CTX_use_RSAPrivateKey_file(); SSL_CTX_check_private_key(); SSL_CTX_load_verify_locations(); // Create a socket sock = socket(); ... connect(sock, ...); // do ssl stuff ssl = SSL_new(ctx); SSL_set_fd (ssl, sock); SSL_connect (ssl); serv_cert = SSL_get_peer_certificate (ssl); ... // print out certificate an close connection // End client The server is doing the following: SSL_library_init(); SSL_load_error_strings(); ctx = SSL_CTX_new(SSLv3_server_method()); SSL_CTX_use_certificate_file(); SSL_CTX_use_PrivateKey_file(); SSL_CTX_check_private_key(); SSL_CTX_set_client_CA_list(ctx, SSL_load_client_CA_file(CERT_CHAIN)); SSL_CTX_load_verify_locations(ctx, CERT_CHAIN, CERT_DIR); SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL); SSL_CTX_set_verify_depth(ctx, 1); // create a listening socket listen_sock = socket (AF_INET, SOCK_STREAM, 0); ... bind(listen_sock, ...); listen(listen_sock, ...); accept (listen_sock, ...); // do ssl stuff ssl = SSL_new (ctx); SSL_set_fd(ssl, ...); SSL_accept(ssl); client_cert = SSL_get_peer_certificate(ssl); ... // print out certificate an close connection // End server The connection works fine and the client gets the server certificate but the server does not get the client certificate. I always get the error "31619:error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned:s3_srvr.c:2010". Running a server with the openssl command line tool gets the certificate from my client so the mistake ought to be in the server`s code. Any ideas? Or, even better, some example code of an working client authentication. btw: Im using OpenSSL 0.9.7d under Gentoo Linux. Big thanks, Uli -- Ulrich Voelkel Eickener Strasse 44a D-41061 Moenchengladbach http://www.ulrich-voelkel.de __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication with Openssl - Apache - errror -12227
Oeps there we do have some kind of a problem the response to: openssl s_client -connect www.bliek.org:443 -prexit Looks like: CONNECTED(0003) depth=0 /C=UK/ST=MyTown/L=Mylocation/O=mydomain.com/OU=Security/CN=www.mydomain.com/[EMAIL PROTECTED] verify error:num=18:self signed certificate verify return:1 depth=0 /C=UK/ST=MyTown/L=Mylocation/O=mydomain.com/OU=Security/CN=www.mydomain.com/[EMAIL PROTECTED] verify return:1 9493:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1052:SSL alert number 40 9493:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226: ... depth=0 /C=UK/ST=MyTown/L=Mylocation/O=mydomain.com/OU=Security/CN=www.mydomain.com/[EMAIL PROTECTED] ... So alright something does go wrong but its yet still unclear to me why. This is how I created the key that resulted in these errors: Create direcroties mkdir /opt/ssl/Server mkdir /opt/ssl/CA mkdir /opt/ssl/Client Create server keys cd /opt/ssl/server openssl req -new > server.cert.csr openssl rsa -in privkey.pem -out server.cert.key openssl x509 -in server.cert.csr -out server.cert.cert -req -signkey server.cert.key -days 365 note: I use CN = www.mydomain.com for all keys Create CA keys cd /opt/ssl/CA openssl req -new > CA.cert.csr openssl rsa -in privkey.pem -out cA.cert.key openssl x509 -in CA.cert.csr -out CA.cert.cert -req -signkey CA.cert.key -days 365 Create Client keys cd /opt/ssl/client openssl req -new > client.cert.csr openssl rsa -in privkey.pem -out client.cert.key openssl x509 -in client.cert.csr -out client.cert.cert -req -signkey client.cert.key -days 365 Sign the client request with the CA.cert.key openssl x509 -req -in client.cert.csr -out client.cert.cert -signkey ../CA/CA.cert.key -CA \ ../CA/CA.cert.cert -CAkey ../CA/CA.cert.key -CAcreateserial -days365 Export cert/keys to server cp /opt/ssl/server/server.cert.cert /etc/apache/conf/ssl/. cp /opt/ssl/server/server.cert.key /etc/apache/conf/ssl/. cp /opt/ssl/CA/CA.cert.cert /etc/apache/conf/ssl/. Edit apache configuration nano -w /etc/apache2/conf/modules.d/41_mod_ssl.default-vhost.conf SSLCertificateFile /path/to/certs/server.cert.cert SSLCertificateKeyFile /path/to/certs/server.cert.key SSLCACertificateFile /path/to/certs/CA.cert.cert SSLVerifyClient require Restart apache server /etc/init.d/apache2 restart note: I do have several vhosts on my machine Export cert to client cp /opt/ssl/client/client.cert/cert -> client machine Import key into browser: start mozilla -> edit -> preferences -> privacy & security -> certificates -> manage certificates -> authorities -> import browse to my www.mydomain.org (not to any of the others vhosts) --- "Dr. Stephen Henson" <[EMAIL PROTECTED]> wrote: > On Tue, Feb 24, 2004, Bo Boe wrote: > > > My mozilla browser (version 1.6) returns the > error. > > When I install the client certificate in iexplorer > > (version 6.0) I get a pop-up window asking me to > > select a client certificate from an empty list. > > > > By the way I just tried to make the certificates > as > > explained in the ssl cookbook on > > http://www.pseudonym.org/ssl/ssl_apache.html > > It results in the same error. > > > > I created all the certificates on an gentoo server > > which is fully up to date. This machine is also > used > > as the apache2 server and openssl 0.9.7c. > > > > http://www.openssl.org/support/faq.html#USER10 > > Steve. > -- > Dr Stephen N. Henson. Email, S/MIME and PGP keys: > see homepage > OpenSSL project core developer and freelance > consultant. > Funding needed! Details on homepage. > Homepage: http://www.drh-consultancy.demon.co.uk > __ > OpenSSL Project > http://www.openssl.org > User Support Mailing List > [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication with Openssl - Apache - errror -12227
On Tue, Feb 24, 2004, Bo Boe wrote: > My mozilla browser (version 1.6) returns the error. > When I install the client certificate in iexplorer > (version 6.0) I get a pop-up window asking me to > select a client certificate from an empty list. > > By the way I just tried to make the certificates as > explained in the ssl cookbook on > http://www.pseudonym.org/ssl/ssl_apache.html > It results in the same error. > > I created all the certificates on an gentoo server > which is fully up to date. This machine is also used > as the apache2 server and openssl 0.9.7c. > http://www.openssl.org/support/faq.html#USER10 Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication with Openssl - Apache - errror -12227
My mozilla browser (version 1.6) returns the error. When I install the client certificate in iexplorer (version 6.0) I get a pop-up window asking me to select a client certificate from an empty list. By the way I just tried to make the certificates as explained in the ssl cookbook on http://www.pseudonym.org/ssl/ssl_apache.html It results in the same error. I created all the certificates on an gentoo server which is fully up to date. This machine is also used as the apache2 server and openssl 0.9.7c. --- Peter Sylvester <[EMAIL PROTECTED]> wrote: > ATTACHMENT part TEXT x-sun-attachment/ __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Client Authentication with Openssl - Apache - errror -12227
I’ve only seen this error when in the SSL process the client is attempting to sign with the private key and errors out. This was with openssl and non-openssl certificates. Mark S -Original Message- From: Bo Boe [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 6:17 AM To: [EMAIL PROTECTED] Subject: Client Authentication with Openssl - Apache - errror -12227 I am trying to set-up a web-server which can only be accessed if the client has a valid & trusted ssl certificate. When I do this I get the following error message: www.mydomain.com has received an incorrect and unexpected message. Error code -12227 So far I have found several other people who have run into this problem but so far none of them have reported the solution. My strong feeling is somehow that the problem is caused by the certificates generated by openssl but I do not have a clear proof of it since there are no entries in the log-files around this error. I posted this problem also on gentoo forum where I have described in more detail how I configured my Apache server and how I created the SSL certificates. Does anyone know how to resolve this problem? Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want.
Re: Client Authentication with IIS 5.0
ES-SE wrote: [...] Hi Ted, thanx for your answer, but that doesn`t be the problem. If I uninstall the root certificate of verisign, I also kann connect and IE presents the verisign client certificate. My own root certificate, with which I signed the client certificate is valid till 2010 and installed on both machines. So there should be another problem.. Hope anybody as an idea.. Thanx a lot for your help Ted!!! Carsten Did I get this right, you uninstalled the VeriSign-Root but you still can connect with your HTTPS-Application? Or does the IE offer the cert the server refuses it? If you can still connect you obviously uninstalled the wrong cert (maybe for the Admin-User, not for the computer-account)... Another thing, did you include crlDistributionPoints or a nsCaRevocationUrl in your user-cert? Then maybe the CRL-verification failed. BTW, if you contact me directly we may talk in german... ;) Ted ;) -- PGP Version: 2.6.3i Public Key Information Download complete Key from ftp://ftp.convey.de/ted/tedkey.asc Key fingerprint = 26 A9 0C 25 60 15 2C B2 D0 F3 A2 31 3D 35 F3 95 smime.p7s Description: S/MIME Cryptographic Signature
Re: Long - Some questions about SSL, Client Authentication...
On Thu, Sep 04, 2003, Ohaya wrote: > One final question... This one may be specific to the behavior of IE, > but I'm not sure: > > 1) I have one server certificate installed in IIS, which I created when > I did the Certificate Server installation. > > 2) In my IE browser, I have two client certificates that I generated and > installed using my Certificate Server, i.e., these 2 client certs have > the same root as the root for the server cert in IIS. > > 3) In my IE browser, I also have a 3rd client certificate, which I got > as a free trial from: > > http://www.globalsign.net/digital_certificate/personalsign/index.cfm > > 4) All 3 of these client certificates are displayed in IE when I do > Tools->Internet Options->Content->Certificates > > Now the question: When I point my IE browser to my IIS with the > "https://"; URL, IE pops up a window asking me which client cert I want > to use. BUT, this window only displays the 2 client certs that I > created using Certificate Server. The GlobalSign cert isn't listed! > > The reason that I was trying this last "experiment" was I was wondering > what would happen if I tried to connect to a server that had a server > cert issued by one CA (my Certificate Server), using IE and a client > cert from a different CA (GlobalSign)? > > Does anyone know why IE doesn't show/list the GlobalSign client cert? > >From what I've read in the SSL protocol doc, it doesn't appear that the > server sends the browser a list of "valid" CAs, so how or why does IE > "know" not to list the GlobalSign client cert? > It does send the client a list of CAs it considers acceptable when it performs client authentication. You can use the OpenSSL s_client tool to see the list. What's probably happening is that the GlobalSign CA isn't included in the list. There are ways to add additional CAs to IIS which it will send when it authenticates a client. I don't have the precise details but the should be in the archives to this group somewhere... Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Long - Some questions about SSL, Client Authentication...
IE only lets you select from certificates that have a root CA in common with the server certificate. This is independent of the web server platform. The web server presents its certificate as part of the SSL handshake, so IE does know the issuing CA from the certification path. Bart... -Original Message- From: Ohaya [mailto:[EMAIL PROTECTED] Sent: 05 September 2003 01:26 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Long - Some questions about SSL, Client Authentication... Hi, I'm new here, and have been "experimenting" with SSL and client authentication and certificates. My current setup is using IE6 and IIS under Win2003 Server, but I have some general questions about SSL and client authentication/certificates that I'm quite puzzled about. I haven't been able to find a good place to discuss this, but I hope that someone here can help!! So far, I've gotten the above (IE and IIS) setup working and talking to each other, with a server certificate installed on the IIS and several client certificates (with different user names) installed on IE. These certs were created using Certificate Server on the Win2003 box. I've read through the SSLV3 protocol doc, etc., and I guess that my main question is when client authentication occurs under SSL, what, exactly, does a successful client authentication "mean"? In reference to this, I'm looking at: http://support.microsoft.com/default.aspx?scid=kb;EN-US;257586 which has a very detailed explanation of the steps that the server actually takes when "authenticating a client", in steps 3 and 4 of the above page in particular. For example, assuming that steps 3 and 4 are successful, can the server really be assured that the DN in the client certificate "accurately" identifies the person who is using the client/IE (i.e., that the person using the client is the person named in the DN of the client certificate)? One final question... This one may be specific to the behavior of IE, but I'm not sure: 1) I have one server certificate installed in IIS, which I created when I did the Certificate Server installation. 2) In my IE browser, I have two client certificates that I generated and installed using my Certificate Server, i.e., these 2 client certs have the same root as the root for the server cert in IIS. 3) In my IE browser, I also have a 3rd client certificate, which I got as a free trial from: http://www.globalsign.net/digital_certificate/personalsign/index.cfm 4) All 3 of these client certificates are displayed in IE when I do Tools->Internet Options->Content->Certificates Now the question: When I point my IE browser to my IIS with the "https://"; URL, IE pops up a window asking me which client cert I want to use. BUT, this window only displays the 2 client certs that I created using Certificate Server. The GlobalSign cert isn't listed! The reason that I was trying this last "experiment" was I was wondering what would happen if I tried to connect to a server that had a server cert issued by one CA (my Certificate Server), using IE and a client cert from a different CA (GlobalSign)? Does anyone know why IE doesn't show/list the GlobalSign client cert? >From what I've read in the SSL protocol doc, it doesn't appear that the server sends the browser a list of "valid" CAs, so how or why does IE "know" not to list the GlobalSign client cert? Does anyone know the answer to the last question? If a browser (e.g., maybe Netscape) were to show all 3 client certs and not "filter" out the GlobalSign client cert, would the SSL client authentication have then failed? And, why? Again, my apologies in advance... Jim __ 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]
Re: [OpenSC-devel] ssl client authentication
On Monday 04 August 2003 21:15, David Mattes wrote: > hi, > > i'm trying to use OpenSSL s_client with OpenSC PKCS#15 engine. the > engine works for operations such as key generation and PKCS#1 > signatures. i've modified the s_client code to be able to use a private > key on the smartcard via the OpenSC engine. i'm running into some > problems with computing signatures for the SSL client verify. i think > the problem is that ssl client verification is a signature computed over > concatenated MD5 and SHA1 hashes of ssl handshake messages. on the > other hand PKCS#1 signature generation expects a DigestInfo structure, Not necessarily, what you need here is to compute a CKM_RSA_PKCS (pkcs11) signature and OpenSC should support this mechanism (if the smartcard key supports it). > which also contains the algorithm identifier for the hash. since there > is no algorithm identifier for MD5-SHA1 concatenation, the opensc engine > doesn't know what to do with the incoming data. can anybody confirm > this? does anybody have some suggestions how to properly address this > issue? > > here are the error messages generated during the connection attempt. > i'm using opensc-20030701 snapshot and openssl-0.9.7b. As the OpenSC padding code has been changed recently please try a more recent OpenSC snapshot. Note: I've successfully tested client authentication using Mozilla with the OpenSC pkcs11 lib. Nils __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ssl client authentication
hi, i'm trying to use OpenSSL s_client with OpenSC PKCS#15 engine. the engine works for operations such as key generation and PKCS#1 signatures. i've modified the s_client code to be able to use a private key on the smartcard via the OpenSC engine. i'm running into some problems with computing signatures for the SSL client verify. i think the problem is that ssl client verification is a signature computed over concatenated MD5 and SHA1 hashes of ssl handshake messages. on the other hand PKCS#1 signature generation expects a DigestInfo structure, which also contains the algorithm identifier for the hash. since there is no algorithm identifier for MD5-SHA1 concatenation, the opensc engine doesn't know what to do with the incoming data. can anybody confirm this? does anybody have some suggestions how to properly address this issue? here are the error messages generated during the connection attempt. i'm using opensc-20030701 snapshot and openssl-0.9.7b. SSL_connect:SSLv3 write client key exchange A pkcs15-sec.c:385:sc_pkcs15_compute_signature: Unable to add padding: Wrong length sc_pkcs15_compute_signature() failed: Wrong lengthSSL_connect:error in SSLv3 write certificate verify A SSL_connect:error in SSLv3 write certificate verify A 19028:error:14099004:SSL routines:SSL3_SEND_CLIENT_VERIFY:RSA lib:s3_clnt.c:1741: = thanks, david __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client authentication
On Tue, Jan 28, 2003 at 11:38:25AM +0530, Chandrasekhar R S wrote: > In my server program, I use SSL_CTX_set_verity(ctx, SSL_VERIFY_PEER | > SSL_VERIFY_FAIL_IF_NO_PEER_CERT,0) to mandate that client cert should be > present. > If present, I use SSL_get_peer_certificate(ssl) to retrieve the client cert. > > In my client program, I use : > > SSL_CTX_use_certificate_file(CTX,CERTF,SSL_FILETYPE_PEM) > SSL_CTX_use_PrivateKey_file(ctx, KEYF, SSL_FILETYPE_PEM) > > calls to load a cert and a key into the client. Use SSL_CTX_check_private_key() to check the correct initialization of the keys. > But, everytime, I run the client and the server, the server complains that > client hasn't presented a cert. Is something else, needs to be done to get > a client cert to the server. Download ssldump from Eric's site and analyze the traffic to see: * whether the client certificate is indeed requested * whether the client does send its certificate or not. > I am using openssl-0.9.7 on HPUX (Unix) systems. I can assure you that it does work on HP-UX :-) serv01 21: uname -a HP-UX serv01 B.10.20 A 9000/780 2002495176 two-user license Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Client authentication
I am to authenticate a client using his certificate. In my server program, I use SSL_CTX_set_verity(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT,0) to mandate that client cert should be present. If present, I use SSL_get_peer_certificate(ssl) to retrieve the client cert. In my client program, I use : SSL_CTX_use_certificate_file(CTX,CERTF,SSL_FILETYPE_PEM) SSL_CTX_use_PrivateKey_file(ctx, KEYF, SSL_FILETYPE_PEM) calls to load a cert and a key into the client. This is from the documentation I found, from Eric Rescorla's "An introduction to OpenSSL programming" notes. But, everytime, I run the client and the server, the server complains that client hasn't presented a cert. Is something else, needs to be done to get a client cert to the server. I am using openssl-0.9.7 on HPUX (Unix) systems. thankful for any help in this regard. Namaste, R S Chandrasekhar [EMAIL PROTECTED] ISD : 091-080-2051166 Telnet : 847-1166 Phone : 2052427 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Unable to configure verify locations for client authentication
I have configured all the SSL parameters and when i start the Apache, i am getting "Unable to configure verify locations for client authentication". PS: I am using opensa. Thanks and have a nice time. Vijay Vangara (SeeBeyond Consultant) Misys Healthcare Systems Ph: (512) 329-0070 x2852 [EMAIL PROTECTED]
Problem with client authentication , apache 2 mod_ssl and java client
Hi All,
I have problem with client authentication. I have setup my CA using openssl
, created server certificate and client certificate both signed by the CA. I
have converted the client certificate to P12 format, imported this into IE6
and ssl communication was successful from Internet explorer browser. I could
pass this SSL information to Tomcat using mod_jk environment variables such
as SSL_CIPHER, SSL_CLIENT_CERT etc...
The problem is when I write a java client like:
Security.addProvider(new
com.sun.net.ssl.internal.ssl.Provider());
System.setProperty("java.protocol.handler.pkgs",
"com.sun.net.ssl.internal.www.protocol");
System.setProperty("javax.net.ssl.keyStore",
"c:/keystore1/java-client.keystore");
System.setProperty("javax.net.ssl.keyStorePassword",
"java-client");
System.setProperty("javax.net.ssl.trustStore",
"c:/keystore1/trust-store.keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "trust-store");
URL u = new
URL("https://esb-reddy:443/simpleservlet";);
URLConnection uc = u.openConnection();
HttpsURLConnection huc = (HttpsURLConnection) uc;
huc.setRequestMethod("GET");
huc.setDoOutput(true);
huc.connect();
I have imported the client certificate into java-client.keystore , which I
have created above using openssl and signed by the CA.
I have also imported the server certificate in to trust-store.keystore.
I got Hand shake failure exception.
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
My error log for mod_ssl shows:
[Tue Sep 24 12:02:17 2002] [error] SSL handshake failed (server
esb-reddy:443, client 10.70.52.170)
[Tue Sep 24 12:02:17 2002] [error] SSL Library Error: 336105671
error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return
a certificate No CAs known to server for verification?
Any one can please help?
Thanks in advance,
Thirumal.
* ** *** ** * ** *** ** * ** *** ** *
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed.
Any views or opinions presented are solely those of the author, and do not necessarily
represent those of ESB.
If you have received this email in error please notify the sender.
Although ESB scans e-mail and attachments for viruses, it does not guarantee
that either are virus-free and accepts no liability for any damage sustained
as a result of viruses.
* ** *** ** * ** *** ** * ** *** ** *
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: Difference in client authentication between sample OpenSSL server and IIS5.
On Tue, May 28, 2002 at 02:59:50PM +0200, Sharon Hezy wrote:
> I'm trying to connect https site on IIS server using my applicative OpenSSL
> client;
> the site is defined as "require SSL channel" and "accept client
> certificate". It means that I
> have to call the site using SSL, but I don't have to pass client certificate
> (it's "accept", not "require").
> So, I started the handshake without supplying client with certificate. IIS
> responded by "500 - Internal Server Error"
> (Actually, he didn't responded at all, but I saw the error code in its log).
Internal Server Error may mean everything, especially it might mean that
IIS had an internal error that has nothing to do with OpenSSL at all.
> Then, I decided to check the client against OpenSSL server : I ran s_server
> (the sample server)
> and checked my client against it - it worked fine in both cases ("accept"
> and "require").So, it seems that
> IIS and OpenSSL servers doing handshake differently. So, I decided to check
> the handshake itself
> (by looking on types of messages that client receives from the server during
> handshake, in both OpenSSL and IIS handshakes).
>
> And this is what I saw:
> In OpenSSL after sending server certificate, server sending certificate
> request (to get client certificate) - it
> doesn't matter at this step if the case is "accept" or "require" - it will
> matter later to the server but not to the
> client and not now. So, client read servers' certificate request and sending
> back certificate message (in my case,
> with empty certificate). And handshake finishes fine and connection goes on.
>
> In IIS, on the other hand, server sending its certificate and then sending
> "SERVER_DONE" message, which means
> that IIS even not trying to ask for certificate from client.
Well, if IIS decides to do so.
> So, I guess, that maybe IIS asking for re-handshake just to ask for client
> certificate ? Is it right?
> If it is - I have two questions:
> 1.How can I support re-handshake in my client? (Maybe code examples ?)
re-handshaking is implemented inside the OpenSSL library and will occur
automatically. Your application will hardly know unless it really tries
to find out :-)
> 2.How can I change this behavior of IIS? (if somebody knows...)
>
> If my guess not seems to be right - maybe somebody can enlighten me?
Please give s_client with the "-bugs" option a try. It will enable several
bug workarounds (SSL_OP_ALL, if you intend to use SSL_CTX_set_options()).
I however don't know, whether this helps.
In any case I consider an "internal server error" to be a problem of your
IIS. See, whether accessing with Netscape, IE etc works and check out
the handshake for comparison. See, whether there are software updates
available for IIS. Or even better: give another good webserver a try:
Apache :-)
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Difference in client authentication between sample OpenSSL server and IIS5.
Hi to all. I’m using 0.9.6.a-engine version (I don’t think that it will matter here), and I have following problem: I’m trying to connect https site on IIS server using my applicative OpenSSL client; the site is defined as “require SSL channel” and “accept client certificate”. It means that I have to call the site using SSL, but I don’t have to pass client certificate (it’s “accept”, not “require”). So, I started the handshake without supplying client with certificate. IIS responded by “500 – Internal Server Error” (Actually, he didn’t responded at all, but I saw the error code in its log). So, I changed site’s restrictions from “ ** Accept** client certificate” to “ **REQUIRE** client certificate”, and supplied my client with client certificate – but, I’ve got the same error on the server. Then, I decided to check the client against OpenSSL server : I ran s_server (the sample server) and checked my client against it – it worked fine in both cases (“accept” and “require”).So, it seems that IIS and OpenSSL servers doing handshake differently. So, I decided to check the handshake itself (by looking on types of messages that client receives from the server during handshake, in both OpenSSL and IIS handshakes). And this is what I saw: In OpenSSL after sending server certificate, server sending certificate request (to get client certificate) – it doesn’t matter at this step if the case is “accept” or “require” – it will matter later to the server but not to the client and not now. So, client read servers’ certificate request and sending back certificate message (in my case, with empty certificate). And handshake finishes fine and connection goes on. In IIS, on the other hand, server sending its certificate and then sending “SERVER_DONE” message, which means that IIS even not trying to ask for certificate from client. So, I guess, that maybe IIS asking for re-handshake just to ask for client certificate ? Is it right? If it is – I have two questions: How can I support re-handshake in my client? (Maybe code examples ?) How can I change this behavior of IIS? (if somebody knows…) If my guess not seems to be right – maybe somebody can enlighten me? If there is some lack of details – just tell! Thank you for reading this long mail, and also to those who will decide to help :-) Sharon.
client authentication errors
Hi, I'm using apache 1.13.9 with mod_ssl 0.9.6 at SuSE Linux 7.2. The client authentication I configured between MSIE 6.0 or Netscape 4.77 as browsers and the apache server works - but also fails. It denies the user from protected sites (those sites that the client authentication is configured for), if the requested certificate is unavailable. So it works. But if it is available, the browser shows the text and some (!) pictures. So it fails. I checked the "access_log" file and it seems that the browser does not request the server for the missing pictures. In the "error_log" file there is one error for each missing picture: [error] mod_ssl: XXL_client authentication failed: unknown reason Is there anybody who has a good idea ? Thanks a lot. Regards, Steffen __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Eric Rescorla wrote: > > Götz Babin-Ebell <[EMAIL PROTECTED]> writes: > > And how gets he the connection IP-Address <-> FQDN ? > > ->He uses DNS. > I think you need to reread his message since that's not > what he says. Hm: client authentication. After a successful SSL_accept() I have some logic that verifies that the Common Name in the client certificate matches the client's DNS name. This works just fine. However, if the It seems to me that if one private key becomes compromised, and I don't validate the DNS name in certificates then an attacker can pretend to be any system in the network until the CRL gets updated. So if I'm understanding things correctly, validation of the DNS name in certificates is quite important. I read this as: 1. client connects to his server 2. server extracts FQDN from cert 3. to be shure the client is really the client for the allowed tasks he does a DNS match for FQDN <-> IP and point 3 is only meaningfull for the client side: you must be shure the server is really the server you wanted to connect, so you know to which host the connection should go. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: Client Authentication Problem
On Wed, 26 Sep 2001 15:21:09 -0700, Michael Sierchio wrote: >David Schwartz wrote: >> Sufficient for what? I may not want to send my credit card >>information to anyone who has a Verisign certificate, but I might be >>willing to send it to someone who has a Verisign certificate for >>'www.amazon.com' or has that listed as one of the alternate names. >There's confusion in the PKI realm about what constitutes trust and >authority. >My assumption is that the certificate issuer does due diligence -- >presumably, that's YOU if you are developing an application using client >auth. No, the application developer may not be the certificate issuer. The application developer (or whoever configured the application to accept certificates signed by a particular authority) must trust the certificate issuer to at least some extent. That extent could vary from total trust to do anything down to trust only for proof of identity. >> Comparing the name to name you get when you resolve the IP you >>connected to doesn't seem useful to me. But comparing the name (or >>alternate name) to the name you expected to connect to makes very good >>sense. >You're talking about connecting to a server via HTTP, which has little if >anything to do with SSL and mutual authentication. I maintain that it is >far easier to poison a DNS cache than to recover someone else's private key >(if reasonably secured). Huh? A secure HTTP connection does use SSL and can use mutual authentication. >Client certs should bind public keys to identity -- however that is defined >by the application. And the application can reasonably do that by checking the name in the certificate and comparing it to the name of the thing the application wanted to send data to. (Assuming the certificate issues is trusted at least to provide accurate identities.) DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
David Schwartz wrote: > Sufficient for what? I may not want to send my credit card information to > anyone who has a Verisign certificate, but I might be willing to send it to > someone who has a Verisign certificate for 'www.amazon.com' or has that > listed as one of the alternate names. There's confusion in the PKI realm about what constitutes trust and authority. My assumption is that the certificate issuer does due diligence -- presumably, that's YOU if you are developing an application using client auth. > Comparing the name to name you get when you resolve the IP you connected to > doesn't seem useful to me. But comparing the name (or alternate name) to the > name you expected to connect to makes very good sense. You're talking about connecting to a server via HTTP, which has little if anything to do with SSL and mutual authentication. I maintain that it is far easier to poison a DNS cache than to recover someone else's private key (if reasonably secured). Client certs should bind public keys to identity -- however that is defined by the application. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Don Zick wrote: Hello Don, > I'm not actually using DNS at all. For the application I'm working with > the TLS clients and servers must be statically configured with a Fully > Qualified Domain Name. I match up the statically configured FQDN for a > client with the DNS name from the client's certificate. You are using DNS. On the network layer you only have the IP address. To get the FQDN you need to use DNS. And compared with certificate / private key authentication it is trivial to forge a wrong DNS answer. (At least if you don't use DNSSEC on all your clients and servers...) When an attacker is able to steal a private key, he is also able to poison your DNS... Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: Client Authentication Problem
On Wed, 26 Sep 2001 09:43:02 -0700, Michael Sierchio wrote: >Don Zick wrote: >> I have recently started using OpenSSL. (I have found the "SSL and TLS" >>book by Eric Rescorla to be invaluable.) I am having a problem with >>client authentication. After a successful SSL_accept() I have some logic >>that verifies that the Common Name in the client certificate matches the >>client's DNS name. This works just fine. However, if the Common Name >>does not contain the client's DNS name, I would like to check for the >>client's DNS name in the subjectAltName extension. This is where I'm >>having a problem. I attempt to check the subjectAltName extension as >>follows: >Why bother binding client certs to a DNS name? In a mutually authenticated >SSL connection, IP addresses may not be important. That each party is in >possession of the private key and the certs are not revoked should be >sufficient. Sufficient for what? I may not want to send my credit card information to anyone who has a Verisign certificate, but I might be willing to send it to someone who has a Verisign certificate for 'www.amazon.com' or has that listed as one of the alternate names. Comparing the name to name you get when you resolve the IP you connected to doesn't seem useful to me. But comparing the name (or alternate name) to the name you expected to connect to makes very good sense. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Götz Babin-Ebell <[EMAIL PROTECTED]> writes: > And how gets he the connection IP-Address <-> FQDN ? > ->He uses DNS. I think you need to reread his message since that's not what he says. > If he wants to allow user XYZ presenting certificate C_XYZ to > do some things, all he has to do is look in an internal > table to map the cert to the allowed tasks. > Introducing the FQDN into this is a useless layer of complexity... This is exactly what he's doing but he wants to use the FQDN as the lookup key. If he knows that the FQDN is in the certificate, this is perfectly reasonable. Consider the case of SMTP-relaying. You wish to ensure that only certain hosts can relay through you which requires determining which each client is. In the old days you'd get their IP and do a reverse lookup. If you require clients to have certificates then you can just ignore the IP, get the certificate and make your access decision off the DN. It's extremely convenient to be able to express these decisions in the language of hostnames, so it's convenient to have the FQDN in the DN and use that for your access control decisions. This has the added advantage that you can express expressions, e.g. allow connections from "*.example.com". Provided that you can trust the CA to only issue certificates with correct FQDNs in them (which people do, since that's required for SSL security) then this is quite a useful procedure. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Michael Sierchio <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > > > There are a number of situations where one wishes to authenticate > > clients based on their DNS names: > > > > (1) SMTP/TLS. > > (2) Secure remote backup. > > > > In such cases the clients often (though not always) have fixed IPs. > > Well, I'll be happy when IPv6 is ubiquitous (coming any day now since 1996!). > Then we can dispense with kludges like DHCP and give globally unique identifiers > as addresses. > > And what about multi-homed hosts? Or many IP addresses per host (using IP aliasing)? I don't see that any of these are really an issue here. The client's IP address isn't being examined at all. The DNS name is simply being used as a unique identifier. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Client Authentication Problem
Eric Rescorla wrote: > > Götz Babin-Ebell <[EMAIL PROTECTED]> writes: > > > [1 ] > > Don Zick wrote: > > > > Hello Don, > > > > > I'm not actually using DNS at all. For the application I'm working with > > > the TLS clients and servers must be statically configured with a Fully > > > Qualified Domain Name. I match up the statically configured FQDN for a > > > client with the DNS name from the client's certificate. > > > > You are using DNS. > > > > On the network layer you only have the IP address. > > To get the FQDN you need to use DNS. > > > > And compared with certificate / private key > > authentication it is trivial to forge a wrong DNS answer. > > (At least if you don't use DNSSEC on all your clients and servers...) > > > > When an attacker is able to steal a private key, > > he is also able to poison your DNS... > I think you're misreading Don's message. He's not looking up the > client's FQDN from the IP, he's extracting it from the verified > certificate. It's perfectly legitimate to use this for authentication > decisions and this doesn't relay on trusting the DNS. And how gets he the connection IP-Address <-> FQDN ? ->He uses DNS. Why should he use the FQDN in the cert for any other uses ? If he wants to allow user XYZ presenting certificate C_XYZ to do some things, all he has to do is look in an internal table to map the cert to the allowed tasks. Introducing the FQDN into this is a useless layer of complexity... > Note that HTTPS behaves essentially this way: you use the DNS to > resolve the IP to connect to the server. You then compare the > server's FQDN (as found in the certificate) against the URL. But this is to avoid trust in a possible poisoned DNS. This needs the private key secure on the server. His plan was to do it the other way round: If an attacker has obtained the private key he wants to prevent missuse with DNS. And that is broken. Bye Goetz -- Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de Sonninstr. 24-28, 20097 Hamburg, Germany Tel.: +49-(0)40 80 80 26 -0, Fax: +49-(0)40 80 80 26 -126 S/MIME Cryptographic Signature
Re: Client Authentication Problem
Eric Rescorla wrote: > There are a number of situations where one wishes to authenticate > clients based on their DNS names: > > (1) SMTP/TLS. > (2) Secure remote backup. > > In such cases the clients often (though not always) have fixed IPs. Well, I'll be happy when IPv6 is ubiquitous (coming any day now since 1996!). Then we can dispense with kludges like DHCP and give globally unique identifiers as addresses. And what about multi-homed hosts? Or many IP addresses per host (using IP aliasing)? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL_connect() on client authentication?
On Mon, Sep 10, 2001 at 04:20:10PM -0700, Henry Yip wrote: > Hi All, > > I have 2 questions. > > 1) > I'm trying to do client authentication from a Server using > PureTLS. On the server side, I call: > socket.sendClose() > socket.close() > when I can't verify the client's host against the certificate chain. > > Now, Should SSL_connect() return an error on the client at this point? Sorry if this kind of off-topic, but using the native openssl libraries SSL_connect returns an error at this point IF the server's SSL is set to verify the client AND the verify locations are set. If you don't set it to this mode, I guess it will accept the connection and SSL_connect will succeed. In my apps using SSL, I usualy handle more than one client, so I set these to the context, and then just create separate SSL connections from it for every client. I use these functions (for the server): SSL_CTX_load_verify_locations to set the file and/or the directory containing the trusted certificates. SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT | SSL_VERIFY_CLIENT_ONCE, my_verify_cb) my_verify_cb can be NULL if you don't want extra diagnostics or don't need to force some verify errors to be ignored. There is more info in the manual pages. Then you load the certificate and private key for the server into the ctx. The server is ready to accept connections. It is a good idea to verify the server from the client using the same verify setting (except for SSL_VERIFY_CLIENT_ONCE). > Seems like select() is not detecting the closed socket condition also. IIRC, select detects a closed socket as a socket ready for reading (and you get 0 bytes when you actualy read). [...] > 2) > If I attempt to do a SSL_Connect() to a port that has a non SSL server > listening, or > do a write() and readv() (non ssl) to a port with a SSL server listening. > Both scenarios > just hangs there. SSL_connect does SSL handshake which involves both reading and writing, it is normal to block if the other side is not acting correctly. The same with reading or writing to somebody who does SSL_accept. > > I just want to confirm this is expected behavior and what's the best way to > recover from this condition? I believe the best way to handle this is > by setting up a timer. Any better ideas? Setting timeouts with openssl is always a good idea. I don't know what's behind those functions, but I had problems with a server blocking on SSL_accept while other connections wait (I put it in the main accept() loop before the fork). The only solution for a single process app is to use non-blocking sockets, but it gets too complicated when you want to SSL_read and it sais you should select for writing ;) Hope this helps a bit -- Players win and winners play Have a lucky day __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
