RE: mutual-TLS / mTLS Example with certificate problem
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Andreas Tengicki > Sent: Thursday, May 07, 2020 03:23 > > 3) myserver vs openssl (and my client) is not working Did you do what I told you to do in my previous message? That is: > > Get rid of the call to use_certificate_file and put everything the server > > should be sending into the chain file, in the order described in the OpenSSL > > documentation: entity certificate, certificate for its issuer, and so on up > > to and including the root. -- Michael Wojcik Distinguished Engineer, Micro Focus
Re: mutual-TLS / mTLS Example with certificate problem
On a tangent, this file format (and order) was actually finally standardized as "application/pem-certificate-chain" by RFC 8555 section 9.1 (the Automatic Certificate Management Environment protocol, or ACME). On Wed, May 6, 2020 at 2:59 PM Michael Wojcik wrote: > Get rid of the call to use_certificate_file and put everything the server > should be sending into the chain file, in the order described in the OpenSSL > documentation: entity certificate, certificate for its issuer, and so on up > to and including the root. (I've just noticed the docs don't say whether > use_certificate_chain_file specifies SSL_BUILD_CHAIN_FLAG_NO_ROOT when it > calls add1_chain_cert, so offhand I don't know whether this will cause the > root to be included in the chain the server sends. But that shouldn't really > matter.)
Re: mutual-TLS / mTLS Example with certificate problem
Hi Andreas, Below repo has examples to use OpenSSL for mTLS (mutual certificate authentication) with sample certificates. You can refer this. https://github.com/TalkWithTLS/TalkWithTLS/blob/master/src/sample/openssl_tls13_server_both_auth.c https://github.com/TalkWithTLS/TalkWithTLS/blob/master/src/sample/openssl_tls13_client_both_auth.c On Thu, May 7, 2020 at 12:36 AM Andreas Tengicki wrote: > Hello, > > I can not find a working mutual-TLS server/client example on github or > the whole internet. Only some example for pieces of code. Communication > via socket without and with encryption (openSSL) is working, but with > mTLS not. I believe that I theoretical understand mTLS, but the practice > will not work. > > The whole (small) project is here: > https://github.com/deckard-rick/mTLS-example > > Server Side > = > > I initialize the SSL-context without errors with (sample, error handling > is not in this email) > > SSL_CTX_set_ecdh_auto(srvCtx->ctx, 1); > SSL_CTX_set_verify(srvCtx->ctx, SSL_VERIFY_PEER or > SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL); > SSL_CTX_load_verify_locations(srvCtx->ctx,NULL,"../certs"); // > SSL_CTX_use_certificate_chain_file(srvCtx->ctx, > "../certs/server/ca.crt"); > SSL_CTX_use_certificate_file(srvCtx->ctx, > "../certs/server/server.crt", SSL_FILETYPE_PEM); > SSL_CTX_use_PrivateKey_file(srvCtx->ctx, > "../certs/server/server.key", SSL_FILETYPE_PEM); > SSL_CTX_check_private_key(srvCtx->ctx); > > the certificates are: > > ca.crt: Version: 3 (0x2) > Serial Number: > 5a:fc:74:e6:28:28:0e:df:5b:7a:50:9e:a8:18:e6:04:42:f0:fd:8d > Signature Algorithm: sha256WithRSAEncryption > Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = > 42CA > Validity Not Before: May 6 09:21:23 2020 GMT Not After : May 6 > 09:21:23 2022 GMT > Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN > = 42CA > > server.crt: Version: 1 (0x0) > Serial Number: > 5f:6f:44:b5:27:47:f2:d2:fe:2b:21:5b:38:7d:e5:f6:e5:d9:c1:23 > Signature Algorithm: sha256WithRSAEncryption > Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = > 42CA > Validity Not Before: May 6 09:30:23 2020 GMT Not After : May 6 > 09:30:23 2021 GMT > Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = > debiandevdesktop01.sdctec.lokal > > debiandevdesktop01.sdctec.lokal is the FQDN of the development server > > Client Side > = > > SSL_CTX_set_ecdh_auto(ctx, 1); > SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL); > SSL_CTX_use_certificate_chain_file(ctx, "../certs/client/ca.crt"); > SSL_CTX_use_certificate_file(ctx, "../certs/client/client.crt", > SSL_FILETYPE_PEM); > SSL_CTX_use_PrivateKey_file(ctx, "../certs/client/client.key", > SSL_FILETYPE_PEM); > > ca.crt: (see server) > > client.crt: Version: 1 (0x0) >Serial Number: > 5f:6f:44:b5:27:47:f2:d2:fe:2b:21:5b:38:7d:e5:f6:e5:d9:c1:24 >Signature Algorithm: sha256WithRSAEncryption >Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 42CA >Validity Not Before: May 6 09:35:51 2020 GMT Not After : May 6 > 09:35:51 2021 GMT >Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = > CLIENT001 > > Error: > = > > If the client connects the server there are the following errors: > > server: > 139918902234240:error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify > failed:../ssl/statem/statem_clnt.c:1915: > > client: > 139918902234240:error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify > failed:../ssl/statem/statem_clnt.c:1915: > > I think, there is a problem with the certificates. But where is the > problem and why? > > The statement to create the certificates are in the project ./certs/ > read.me > > Thanks for any help, I'm looking since days for a solution and I believe > it is only a small bug. > > Best regards > > Andreas > > >
Re: mutual-TLS / mTLS Example with certificate problem
Hello Michael, thank you and Viktor for your fast help. Viktor annotations I don't fully understand. Sure there is the openssl test server and client, but the source code is complex for everyone who is new in this encryption tasks. But testing with openssl was a valuable notice: 1) openssl vs openssl openssl s_server -port 8080 -CAfile certs/server/ca.crt -cert certs/server/server.crt -key certs/server/server.key -Verify 99 Is this the right call for "TLS with mutual authentication", I cannot find an other parameter for SSL_VERIFY_PEER? with openssl s_client -connect localhost:8080 -CAfile certs/client/ca.crt -cert certs/client/client.crt -key certs/client/client.key it is working, and the server sees the COMMON NAME of the client (the whole certificate) 2) openssl vs myclient is working 3) myserver vs openssl (and my client) is not working In the openssl server command line I set only CAfile, cert, key and verify I believe I do this also in my source code: int verify_flags = SSL_VERIFY_PEER SSL_CTX_set_verify(srvCtx->ctx, verify_flags, NULL); char cafile[] = "/home/debdev/Projects/clearing/server/certs/client/ca.crt"; Variant 1: SSL_CTX_use_certificate_chain_file(srvCtx->ctx, cafile) Variant 2: STACK_OF(X509_NAME) *calist = SSL_load_client_CA_file(cafile); SSL_CTX_set_client_CA_list(srvCtx->ctx, calist); if (SSL_CTX_use_certificate_file(srvCtx->ctx, srvCtx->cert, SSL_FILETYPE_PEM) <= 0) if (SSL_CTX_use_PrivateKey_file(srvCtx->ctx, srvCtx->key, SSL_FILETYPE_PEM) <= 0 ) But there is still the error: tls_process_client_certificate:certificate verify failed Why? 4) I have looked into apps/s_server.c there is a ctx_set_verify_locations with the cafile information in apps.c this calls: SSL_CTX_load_verify_file, but the compiler can't find this function. Why? Thanks and sorry if I do not understand all details in the first try. Best regards Andreas Am 06.05.2020 um 21:59 schrieb Michael Wojcik: >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of >> Andreas Tengicki >> Sent: Wednesday, May 06, 2020 12:45 >> To: openssl-users@openssl.org >> Subject: mutual-TLS / mTLS Example with certificate problem >> >> I can not find a working mutual-TLS server/client example on github or >> the whole internet. > By "mutual-TLS" I assume you mean "TLS with mutual authentication". > > I don't know about open-source examples off the top of my head, but all the > products I work on support mutual authentication. > > Oh, wait, of course I know of an open-source example. It's OpenSSL, which > supports mutual authentication in the s_server and s_client apps. > >> SSL_CTX_use_certificate_chain_file(srvCtx->ctx, >> "../certs/server/ca.crt"); >> SSL_CTX_use_certificate_file(srvCtx->ctx, >> "../certs/server/server.crt", SSL_FILETYPE_PEM); > This is very likely wrong. SSL(_CTX)_use_certificate_chain_file sets the > entity certificate and its (partial) chain. So when you call > SSL_CTX_use_certificate_file you're overwriting the entity certificate set by > use_certificate_chain_file. > > Get rid of the call to use_certificate_file and put everything the server > should be sending into the chain file, in the order described in the OpenSSL > documentation: entity certificate, certificate for its issuer, and so on up > to and including the root. (I've just noticed the docs don't say whether > use_certificate_chain_file specifies SSL_BUILD_CHAIN_FLAG_NO_ROOT when it > calls add1_chain_cert, so offhand I don't know whether this will cause the > root to be included in the chain the server sends. But that shouldn't really > matter.) > >> ca.crt: Version: 3 (0x2) >> Serial Number: >> 5a:fc:74:e6:28:28:0e:df:5b:7a:50:9e:a8:18:e6:04:42:f0:fd:8d >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 42CA >> Validity Not Before: May 6 09:21:23 2020 GMT Not After : May 6 >> 09:21:23 2022 GMT >> Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN >> = 42CA > Not enough information. We don't know what the Basic Constraints are for this > certificate, or EKU, or whether it's actually the certificate that signed > your server's entity certificate. > > More importantly, if this is the only certificate in ca.crt, which was what > you passed to use_certificate_chain_file, then this was stored in the context > as the entity cert, and no certificates were added to the chain. Then you > overwrote the entity cert with use_certificate_file, and you still have no > chain. > > (At least I believe that's what wil
Re: mutual-TLS / mTLS Example with certificate problem
On 06/05/2020 19:44, Andreas Tengicki wrote: > SSL_CTX_set_ecdh_auto(srvCtx->ctx, 1); Viktor and Michael have already provided some excellent advice on this so I won't cover the same ground. Just one note on this line though - this is actually unnecessary in modern versions of OpenSSL (anything from OpenSSL 1.1.0 and above). It's a no-op in modern versions - "auto" ecdh is the default. Matt
RE: mutual-TLS / mTLS Example with certificate problem
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Andreas Tengicki > Sent: Wednesday, May 06, 2020 12:45 > To: openssl-users@openssl.org > Subject: mutual-TLS / mTLS Example with certificate problem > > I can not find a working mutual-TLS server/client example on github or > the whole internet. By "mutual-TLS" I assume you mean "TLS with mutual authentication". I don't know about open-source examples off the top of my head, but all the products I work on support mutual authentication. Oh, wait, of course I know of an open-source example. It's OpenSSL, which supports mutual authentication in the s_server and s_client apps. > SSL_CTX_use_certificate_chain_file(srvCtx->ctx, > "../certs/server/ca.crt"); > SSL_CTX_use_certificate_file(srvCtx->ctx, > "../certs/server/server.crt", SSL_FILETYPE_PEM); This is very likely wrong. SSL(_CTX)_use_certificate_chain_file sets the entity certificate and its (partial) chain. So when you call SSL_CTX_use_certificate_file you're overwriting the entity certificate set by use_certificate_chain_file. Get rid of the call to use_certificate_file and put everything the server should be sending into the chain file, in the order described in the OpenSSL documentation: entity certificate, certificate for its issuer, and so on up to and including the root. (I've just noticed the docs don't say whether use_certificate_chain_file specifies SSL_BUILD_CHAIN_FLAG_NO_ROOT when it calls add1_chain_cert, so offhand I don't know whether this will cause the root to be included in the chain the server sends. But that shouldn't really matter.) > ca.crt: Version: 3 (0x2) > Serial Number: > 5a:fc:74:e6:28:28:0e:df:5b:7a:50:9e:a8:18:e6:04:42:f0:fd:8d > Signature Algorithm: sha256WithRSAEncryption > Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 42CA > Validity Not Before: May 6 09:21:23 2020 GMT Not After : May 6 > 09:21:23 2022 GMT > Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN > = 42CA Not enough information. We don't know what the Basic Constraints are for this certificate, or EKU, or whether it's actually the certificate that signed your server's entity certificate. More importantly, if this is the only certificate in ca.crt, which was what you passed to use_certificate_chain_file, then this was stored in the context as the entity cert, and no certificates were added to the chain. Then you overwrote the entity cert with use_certificate_file, and you still have no chain. (At least I believe that's what will happen; I haven't actually tried it.) > server.crt: Version: 1 (0x0) X.509v1? PKIX moved to v3 in, what, 2002 (with RFC 3280)? I mean, X.509v1 ought to still work, but it's hardly good practice. > Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = > debiandevdesktop01.sdctec.lokal > > debiandevdesktop01.sdctec.lokal is the FQDN of the development server And is that exactly what the client is specifying when it tries to verify the server's certificate? > SSL_CTX_use_certificate_chain_file(ctx, "../certs/client/ca.crt"); > SSL_CTX_use_certificate_file(ctx, "../certs/client/client.crt", > SSL_FILETYPE_PEM); Same problem as above. > If the client connects the server there are the following errors: > > server: > 139918902234240:error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify > failed:../ssl/statem/statem_clnt.c:1915: Is that the whole OpenSSL error stack? When reporting an OpenSSL error (from your application), you should always make sure to dump the whole stack. Also, a piece of advice: A good place to start when diagnosing issues like this is to swap out the server for openssl s_server, or the client for openssl s_client. s_client can give you a whole bunch of information about what the server is sending, and would have shown the chain is just the entity certificate in this case. -- Michael Wojcik Distinguished Engineer, Micro Focus
Re: mutual-TLS / mTLS Example with certificate problem
On Wed, May 06, 2020 at 08:44:57PM +0200, Andreas Tengicki wrote: > SSL_CTX_load_verify_locations(srvCtx->ctx,NULL,"../certs"); // Have you run "c_rehash" on "../certs" (not keen on relative file names here myself). > Client Side > = > > SSL_CTX_set_ecdh_auto(ctx, 1); > SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL); > SSL_CTX_use_certificate_chain_file(ctx, "../certs/client/ca.crt"); > SSL_CTX_use_certificate_file(ctx, "../certs/client/client.crt", > SSL_FILETYPE_PEM); > SSL_CTX_use_PrivateKey_file(ctx, "../certs/client/client.key", > SSL_FILETYPE_PEM); What is the client doing for "verify_locations"? -- Viktor.
Re: mutual-TLS / mTLS Example with certificate problem
On Wed, May 06, 2020 at 08:44:57PM +0200, Andreas Tengicki wrote:
> I can not find a working mutual-TLS server/client example on github or
> the whole internet. Only some example for pieces of code. Communication
> via socket without and with encryption (openSSL) is working, but with
> mTLS not. I believe that I theoretical understand mTLS, but the practice
> will not work.
Postfix uses an "ask_ccert" configuration boolean to solicit client
certificates. The associated server-side code (with the SNI ctx
side-effects elided) is:
if (props->ask_ccert)
verify_flags = SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE;
SSL_CTX_set_verify(server_ctx, verify_flags,
tls_verify_certificate_callback);
if (props->ask_ccert && *props->CAfile) {
STACK_OF(X509_NAME) *calist = SSL_load_client_CA_file(props->CAfile);
if (calist == 0) {
/* Not generally critical */
msg_warn("error loading client CA names from: %s",
props->CAfile);
tls_print_errors();
}
SSL_CTX_set_client_CA_list(server_ctx, calist);
}
Some clients will not send a certificate unless the server-side client
CA list is non-empty and includes the root CA that issued the client's
cert.
> SSL_CTX_set_ecdh_auto(ctx, 1);
> SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);
> SSL_CTX_use_certificate_chain_file(ctx, "../certs/client/ca.crt");
> SSL_CTX_use_certificate_file(ctx, "../certs/client/client.crt",
> SSL_FILETYPE_PEM);
> SSL_CTX_use_PrivateKey_file(ctx, "../certs/client/client.key",
> SSL_FILETYPE_PEM);
You SHOULD NOT specify both a certificate chain file and certificate
file. The ..._chain_file() function loads the leaf cert, and then the
rest of the chain.
>
> server:
> 139918902234240:error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify
> failed:../ssl/statem/statem_clnt.c:1915:
Your trust stores don't contain the requisite CAs and/or the chain files
are missing required intermediate certs.
--
Viktor.
mutual-TLS / mTLS Example with certificate problem
Hello, I can not find a working mutual-TLS server/client example on github or the whole internet. Only some example for pieces of code. Communication via socket without and with encryption (openSSL) is working, but with mTLS not. I believe that I theoretical understand mTLS, but the practice will not work. The whole (small) project is here: https://github.com/deckard-rick/mTLS-example Server Side = I initialize the SSL-context without errors with (sample, error handling is not in this email) SSL_CTX_set_ecdh_auto(srvCtx->ctx, 1); SSL_CTX_set_verify(srvCtx->ctx, SSL_VERIFY_PEER or SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL); SSL_CTX_load_verify_locations(srvCtx->ctx,NULL,"../certs"); // SSL_CTX_use_certificate_chain_file(srvCtx->ctx, "../certs/server/ca.crt"); SSL_CTX_use_certificate_file(srvCtx->ctx, "../certs/server/server.crt", SSL_FILETYPE_PEM); SSL_CTX_use_PrivateKey_file(srvCtx->ctx, "../certs/server/server.key", SSL_FILETYPE_PEM); SSL_CTX_check_private_key(srvCtx->ctx); the certificates are: ca.crt: Version: 3 (0x2) Serial Number: 5a:fc:74:e6:28:28:0e:df:5b:7a:50:9e:a8:18:e6:04:42:f0:fd:8d Signature Algorithm: sha256WithRSAEncryption Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 42CA Validity Not Before: May 6 09:21:23 2020 GMT Not After : May 6 09:21:23 2022 GMT Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 42CA server.crt: Version: 1 (0x0) Serial Number: 5f:6f:44:b5:27:47:f2:d2:fe:2b:21:5b:38:7d:e5:f6:e5:d9:c1:23 Signature Algorithm: sha256WithRSAEncryption Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 42CA Validity Not Before: May 6 09:30:23 2020 GMT Not After : May 6 09:30:23 2021 GMT Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = debiandevdesktop01.sdctec.lokal debiandevdesktop01.sdctec.lokal is the FQDN of the development server Client Side = SSL_CTX_set_ecdh_auto(ctx, 1); SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL); SSL_CTX_use_certificate_chain_file(ctx, "../certs/client/ca.crt"); SSL_CTX_use_certificate_file(ctx, "../certs/client/client.crt", SSL_FILETYPE_PEM); SSL_CTX_use_PrivateKey_file(ctx, "../certs/client/client.key", SSL_FILETYPE_PEM); ca.crt: (see server) client.crt: Version: 1 (0x0) Serial Number: 5f:6f:44:b5:27:47:f2:d2:fe:2b:21:5b:38:7d:e5:f6:e5:d9:c1:24 Signature Algorithm: sha256WithRSAEncryption Issuer: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = 42CA Validity Not Before: May 6 09:35:51 2020 GMT Not After : May 6 09:35:51 2021 GMT Subject: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = CLIENT001 Error: = If the client connects the server there are the following errors: server: 139918902234240:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: client: 139918902234240:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: I think, there is a problem with the certificates. But where is the problem and why? The statement to create the certificates are in the project ./certs/read.me Thanks for any help, I'm looking since days for a solution and I believe it is only a small bug. Best regards Andreas
Re: Certificate problem - SOLVED
From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, July 08, 2014 20:33 On Tue, Jul 8, 2014 at 7:00 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, July 08, 2014 16:20 ... Not sure if this is any consolation, but countryName is a DirectoryString, and PrintableString is OK per RFC 5280 (http://tools.ietf.org/html/rfc5280#section-4.1.2.6): Actually it's not. 4.1.2.4 Issuer says Name.RDN.AVA values are 'generally' DirectoryString, but see appendix A on p115: countryName is PrintableString size(2), presumably because its allowed values are from ISO 3166 which in turn uses ASCII letters. So countryName is not PrintableString? countryName IS PrintableString. countryName is specified as exactly PrintableString, unlike other fields which are specified as DirectoryString where DirectoryString is CHOICE that includes PrintableString as one option so those fields MAY BE PrintableString. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Comparison trickery (Was: Certificate problem - SOLVED)
Op 9 jul. 2014, om 02:33 heeft Jeffrey Walton noloa...@gmail.com het volgende geschreven: On Tue, Jul 8, 2014 at 7:00 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, July 08, 2014 16:20 ... Not sure if this is any consolation, but countryName is a DirectoryString, and PrintableString is OK per RFC 5280 (http://tools.ietf.org/html/rfc5280#section-4.1.2.6): Actually it's not. 4.1.2.4 Issuer says Name.RDN.AVA values are 'generally' DirectoryString, but see appendix A on p115: countryName is PrintableString size(2), presumably because its allowed values are from ISO 3166 which in turn uses ASCII letters. So countryName is not PrintableString? Slightly off topic - we did encounter a situation not very long ago where an attempt was made to evade specific firewall rules on a DN by having one of the RDNs (from memory it was the CN) not be the usual UTF8String(0xC) but an IA5String(0x16) - while relying on the app-side infrastructure to match them at application/java compareTo(). Dw.
RE: Certificate problem - SOLVED
I figured it out and am now wondering if there is a defect in the openssl verify command. This suggestion from Dave Thompson: I would first try x509 -noout -subject|issuer -nameopt multiline,show_type and see if that helps. Pointed me in the right direction. What i found was that Issuer for certificate A, which was the one that was NOT working, looked like this: [cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt multiline,show_type -in CertA.pem issuer= countryName = UTF8STRING:US stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view While the issuer for certificate B and subject for my CA looked like this: [cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt multiline,show_type -in CertB.pem issuer= countryName = PRINTABLESTRING:US stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view [cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt multiline,show_type -in CA.pem issuer= countryName = PRINTABLESTRING:US stateOrProvinceName = UTF8STRING:New York organizationName = UTF8STRING:Allworx Corp, a Windstream Company commonName= UTF8STRING:view So it looks like openssl verify is not taking the type of countryName into account while the browsers are. Is this expected behavior or a defect? Again, thanks for all the help everybody! CHAD From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of Dave Thompson [dthomp...@prinpay.com] Sent: Monday, July 07, 2014 4:03 PM To: openssl-users@openssl.org Subject: RE: Certificate problem From: owner-openssl-us...@openssl.org On Behalf Of Barbe, Charles Sent: Sunday, July 06, 2014 22:42 I have the following certificates and associated private keys: A - certificate A generated with one version of my software not using openssl B - certificate B generated with a new version of my software that does use openssl CA - a local certificate authority whose private key is used to sign both A and B I can verify both A and B using openssl verify using CA as the cafile argument. However, when I install CA on a client and try to connect a web browser to my server running the two different versions of software, they complain that they cannot find the issuer with A but not with B. I have examined both certificates and cannot find anything different about them. As far as I can tell, the only difference is that B used openssl to generate the certificate and A used our own custom software. The odd thing to me is that openssl verify can verify both just fine. What are the web browsers doing different? I've tried chrome, Firefox and opera and all behave the same... Accepting B and rejecting A. Does anybody have any suggestions on where to look to figure this out? A tool to use? You are installing in the correct placeS which can be different per browser, right? The only thing that springs to mind that could be invisible is string types and some options of the cert Issuer fields vs the CA Subject. RFC 5280 requires a fairly complicated Unicode-aware comparison algorithm which I believe openssl does (it definitely canonicalizes before comparison, but I haven't gone through the canonicalization to make sure it exactly matches the RFC); browsers might not do the same (perhaps indirectly) although I'd be surprised if NONE do. I would first try x509 -noout -subject|issuer -nameopt multiline,show_type and see if that helps. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org CA.pem Description: CA.pem CertA.pem Description: CertA.pem
Re: Certificate problem - SOLVED
On Tue, Jul 8, 2014 at 3:39 PM, Barbe, Charles
charles.ba...@allworx.com wrote:
I figured it out and am now wondering if there is a defect in the openssl
verify command. This suggestion from Dave Thompson:
I would first try x509 -noout -subject|issuer -nameopt multiline,show_type
and see if that helps.
Pointed me in the right direction. What i found was that Issuer for
certificate A, which was the one that was NOT working, looked like this:
[cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt
multiline,show_type -in CertA.pem
issuer=
countryName = UTF8STRING:US
stateOrProvinceName = UTF8STRING:New York
organizationName = UTF8STRING:Allworx Corp, a Windstream Company
commonName= UTF8STRING:view
While the issuer for certificate B and subject for my CA looked like this:
[cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt
multiline,show_type -in CertB.pem
issuer=
countryName = PRINTABLESTRING:US
stateOrProvinceName = UTF8STRING:New York
organizationName = UTF8STRING:Allworx Corp, a Windstream Company
commonName= UTF8STRING:view
[cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt
multiline,show_type -in CA.pem
issuer=
countryName = PRINTABLESTRING:US
stateOrProvinceName = UTF8STRING:New York
organizationName = UTF8STRING:Allworx Corp, a Windstream Company
commonName= UTF8STRING:view
So it looks like openssl verify is not taking the type of countryName into
account while the browsers are. Is this expected behavior or a defect?
Not sure if this is any consolation, but countryName is a
DirectoryString, and PrintableString is OK per RFC 5280
(http://tools.ietf.org/html/rfc5280#section-4.1.2.6):
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)) }
However, there is the following on page 23:
When encoding attribute values of type DirectoryString, conforming
CAs MUST use PrintableString or UTF8String encoding, with the
following exceptions:
(a) When the subject of the certificate is a CA, the subject
field MUST be encoded in the same way as it is encoded in the
issuer field (Section 4.1.2.4) in all certificates issued by
the subject CA. Thus, if the subject CA encodes attributes
in the issuer fields of certificates that it issues using the
TeletexString, BMPString, or UniversalString encodings, then
the subject field of certificates issued to that CA MUST use
the same encoding.
So the DirectoryString must be the same type. You can't make it
utf8String in the server certificate's issuer and PrintableString in
the CA's subject.
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Certificate problem - SOLVED
Yet openssl verify said OK to both of my certificates against the CA
certificate... so is it incorrectly neglecting to compare the types when it
tries to build the chain of certificates?
Charles A. Barbe
Senior Software Engineer
Allworx, a Windstream company
245 East Main St | Rochester NY | 14604
charles.ba...@allworx.com | 585.421.5565
From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on
behalf of Jeffrey Walton [noloa...@gmail.com]
Sent: Tuesday, July 08, 2014 4:19 PM
To: OpenSSL Users List
Subject: Re: Certificate problem - SOLVED
On Tue, Jul 8, 2014 at 3:39 PM, Barbe, Charles
charles.ba...@allworx.com wrote:
I figured it out and am now wondering if there is a defect in the openssl
verify command. This suggestion from Dave Thompson:
I would first try x509 -noout -subject|issuer -nameopt multiline,show_type
and see if that helps.
Pointed me in the right direction. What i found was that Issuer for
certificate A, which was the one that was NOT working, looked like this:
[cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt
multiline,show_type -in CertA.pem
issuer=
countryName = UTF8STRING:US
stateOrProvinceName = UTF8STRING:New York
organizationName = UTF8STRING:Allworx Corp, a Windstream Company
commonName= UTF8STRING:view
While the issuer for certificate B and subject for my CA looked like this:
[cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt
multiline,show_type -in CertB.pem
issuer=
countryName = PRINTABLESTRING:US
stateOrProvinceName = UTF8STRING:New York
organizationName = UTF8STRING:Allworx Corp, a Windstream Company
commonName= UTF8STRING:view
[cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt
multiline,show_type -in CA.pem
issuer=
countryName = PRINTABLESTRING:US
stateOrProvinceName = UTF8STRING:New York
organizationName = UTF8STRING:Allworx Corp, a Windstream Company
commonName= UTF8STRING:view
So it looks like openssl verify is not taking the type of countryName into
account while the browsers are. Is this expected behavior or a defect?
Not sure if this is any consolation, but countryName is a
DirectoryString, and PrintableString is OK per RFC 5280
(http://tools.ietf.org/html/rfc5280#section-4.1.2.6):
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)) }
However, there is the following on page 23:
When encoding attribute values of type DirectoryString, conforming
CAs MUST use PrintableString or UTF8String encoding, with the
following exceptions:
(a) When the subject of the certificate is a CA, the subject
field MUST be encoded in the same way as it is encoded in the
issuer field (Section 4.1.2.4) in all certificates issued by
the subject CA. Thus, if the subject CA encodes attributes
in the issuer fields of certificates that it issues using the
TeletexString, BMPString, or UniversalString encodings, then
the subject field of certificates issued to that CA MUST use
the same encoding.
So the DirectoryString must be the same type. You can't make it
utf8String in the server certificate's issuer and PrintableString in
the CA's subject.
Jeff
__
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: Certificate problem - SOLVED
Also don't these lines of the spec:
countryName ATTRIBUTE ::= {
WITH SYNTAX PrintableString (SIZE (2))
-- IS 3166 codes only
ID id-at-countryName }
indicate that countryName is restricted to the PrintableString (SIZE (2)) type
which is a restricted subset of DirectoryString?
Charles A. Barbe
Senior Software Engineer
Allworx, a Windstream company
245 East Main St | Rochester NY | 14604
charles.ba...@allworx.com | 585.421.5565
From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on
behalf of Barbe, Charles [charles.ba...@allworx.com]
Sent: Tuesday, July 08, 2014 4:44 PM
To: openssl-users@openssl.org
Subject: RE: Certificate problem - SOLVED
Yet openssl verify said OK to both of my certificates against the CA
certificate... so is it incorrectly neglecting to compare the types when it
tries to build the chain of certificates?
Charles A. Barbe
Senior Software Engineer
Allworx, a Windstream company
245 East Main St | Rochester NY | 14604
charles.ba...@allworx.com | 585.421.5565
From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on
behalf of Jeffrey Walton [noloa...@gmail.com]
Sent: Tuesday, July 08, 2014 4:19 PM
To: OpenSSL Users List
Subject: Re: Certificate problem - SOLVED
On Tue, Jul 8, 2014 at 3:39 PM, Barbe, Charles
charles.ba...@allworx.com wrote:
I figured it out and am now wondering if there is a defect in the openssl
verify command. This suggestion from Dave Thompson:
I would first try x509 -noout -subject|issuer -nameopt multiline,show_type
and see if that helps.
Pointed me in the right direction. What i found was that Issuer for
certificate A, which was the one that was NOT working, looked like this:
[cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt
multiline,show_type -in CertA.pem
issuer=
countryName = UTF8STRING:US
stateOrProvinceName = UTF8STRING:New York
organizationName = UTF8STRING:Allworx Corp, a Windstream Company
commonName= UTF8STRING:view
While the issuer for certificate B and subject for my CA looked like this:
[cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt
multiline,show_type -in CertB.pem
issuer=
countryName = PRINTABLESTRING:US
stateOrProvinceName = UTF8STRING:New York
organizationName = UTF8STRING:Allworx Corp, a Windstream Company
commonName= UTF8STRING:view
[cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -nameopt
multiline,show_type -in CA.pem
issuer=
countryName = PRINTABLESTRING:US
stateOrProvinceName = UTF8STRING:New York
organizationName = UTF8STRING:Allworx Corp, a Windstream Company
commonName= UTF8STRING:view
So it looks like openssl verify is not taking the type of countryName into
account while the browsers are. Is this expected behavior or a defect?
Not sure if this is any consolation, but countryName is a
DirectoryString, and PrintableString is OK per RFC 5280
(http://tools.ietf.org/html/rfc5280#section-4.1.2.6):
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)) }
However, there is the following on page 23:
When encoding attribute values of type DirectoryString, conforming
CAs MUST use PrintableString or UTF8String encoding, with the
following exceptions:
(a) When the subject of the certificate is a CA, the subject
field MUST be encoded in the same way as it is encoded in the
issuer field (Section 4.1.2.4) in all certificates issued by
the subject CA. Thus, if the subject CA encodes attributes
in the issuer fields of certificates that it issues using the
TeletexString, BMPString, or UniversalString encodings, then
the subject field of certificates issued to that CA MUST use
the same encoding.
So the DirectoryString must be the same type. You can't make it
utf8String in the server certificate's issuer and PrintableString in
the CA's subject.
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http
Re: Certificate problem - SOLVED
On Tue, Jul 8, 2014 at 4:48 PM, Barbe, Charles
charles.ba...@allworx.com wrote:
Also don't these lines of the spec:
countryName ATTRIBUTE ::= {
WITH SYNTAX PrintableString (SIZE (2))
-- IS 3166 codes only
ID id-at-countryName }
indicate that countryName is restricted to the PrintableString (SIZE (2))
type which is a restricted subset of DirectoryString?
That may apply. I see it under A.1. Explicitly Tagged Module, 1988
Syntax, but I'm not sure what the introduction is telling me in
Appendix A.
If it matters... looking at CA and server certificates I created
using OpenSSL's API (a few months ago) show the country code is
PRINTABLESTRING in both.
Jeff
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Certificate problem - SOLVED
From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton
Sent: Tuesday, July 08, 2014 16:20
On Tue, Jul 8, 2014 at 3:39 PM, Barbe, Charles
charles.ba...@allworx.com wrote:
I figured it out and am now wondering if there is a defect in the openssl
verify command. This suggestion from Dave Thompson:
I would first try x509 -noout -subject|issuer -nameopt multiline,show_type
and see if that helps.
Pointed me in the right direction. What i found was that Issuer for
certificate A, which was the one that was NOT working, looked like this:
[cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -
nameopt multiline,show_type -in CertA.pem
issuer=
countryName = UTF8STRING:US
snip
While the issuer for certificate B and subject for my CA looked like this:
[cbarbe@localhost foropensslusers]$ openssl x509 -noout -issuer -
nameopt multiline,show_type -in CertB.pem
issuer=
countryName = PRINTABLESTRING:US
snip
So it looks like openssl verify is not taking the type of countryName into
account while the browsers are. Is this
expected behavior or a defect?
Not sure if this is any consolation, but countryName is a
DirectoryString, and PrintableString is OK per RFC 5280
(http://tools.ietf.org/html/rfc5280#section-4.1.2.6):
Actually it's not. 4.1.2.4 Issuer says Name.RDN.AVA values are
'generally' DirectoryString, but see appendix A on p115:
countryName is PrintableString size(2), presumably because its
allowed values are from ISO 3166 which in turn uses ASCII letters.
Similarly dnQualifier is PrintableString and emailAddress is IA5String.
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)) }
However, there is the following on page 23:
When encoding attribute values of type DirectoryString, conforming
CAs MUST use PrintableString or UTF8String encoding, with the
following exceptions:
(a) When the subject of the certificate is a CA, the subject
field MUST be encoded in the same way as it is encoded in the
issuer field (Section 4.1.2.4) in all certificates issued by
the subject CA. Thus, if the subject CA encodes attributes
in the issuer fields of certificates that it issues using the
TeletexString, BMPString, or UniversalString encodings, then
the subject field of certificates issued to that CA MUST use
the same encoding.
So the DirectoryString must be the same type. You can't make it
utf8String in the server certificate's issuer and PrintableString in
the CA's subject.
4.1.2.4 says name matching should use the rules in 7.1, which allow
'insignifcant' variations in the string values, and doesn't say anything
specific I can find about the encoding.
I'm not sure if X.509/X.has quite the same rules, or if CA's have
historically done so (for certs that might still be usable).
OpenSSL is generally pretty Postelian in accepting slightly 'broken'
protocols and data to maximize interoperability. But 1.0.2 is slated
to enhance chain validation, and checks like this might fit in there
better than in the past flag bits that always run out approach.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Certificate problem
On Mon, Jul 07, 2014, Dave Thompson wrote: The only thing that springs to mind that could be invisible is string types and some options of the cert Issuer fields vs the CA Subject. RFC 5280 requires a fairly complicated Unicode-aware comparison algorithm which I believe openssl does (it definitely canonicalizes before comparison, but I haven't gone through the canonicalization to make sure it exactly matches the RFC); browsers might not do the same (perhaps indirectly) although I'd be surprised if NONE do. OpenSSL currently doesn't perform the full canonicalisation of RFC5280. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate problem - SOLVED
On Tue, Jul 8, 2014 at 7:00 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton Sent: Tuesday, July 08, 2014 16:20 ... Not sure if this is any consolation, but countryName is a DirectoryString, and PrintableString is OK per RFC 5280 (http://tools.ietf.org/html/rfc5280#section-4.1.2.6): Actually it's not. 4.1.2.4 Issuer says Name.RDN.AVA values are 'generally' DirectoryString, but see appendix A on p115: countryName is PrintableString size(2), presumably because its allowed values are from ISO 3166 which in turn uses ASCII letters. So countryName is not PrintableString? Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Certificate problem
From: owner-openssl-us...@openssl.org On Behalf Of Barbe, Charles Sent: Sunday, July 06, 2014 22:42 I have the following certificates and associated private keys: A - certificate A generated with one version of my software not using openssl B - certificate B generated with a new version of my software that does use openssl CA - a local certificate authority whose private key is used to sign both A and B I can verify both A and B using openssl verify using CA as the cafile argument. However, when I install CA on a client and try to connect a web browser to my server running the two different versions of software, they complain that they cannot find the issuer with A but not with B. I have examined both certificates and cannot find anything different about them. As far as I can tell, the only difference is that B used openssl to generate the certificate and A used our own custom software. The odd thing to me is that openssl verify can verify both just fine. What are the web browsers doing different? I've tried chrome, Firefox and opera and all behave the same... Accepting B and rejecting A. Does anybody have any suggestions on where to look to figure this out? A tool to use? You are installing in the correct placeS which can be different per browser, right? The only thing that springs to mind that could be invisible is string types and some options of the cert Issuer fields vs the CA Subject. RFC 5280 requires a fairly complicated Unicode-aware comparison algorithm which I believe openssl does (it definitely canonicalizes before comparison, but I haven't gone through the canonicalization to make sure it exactly matches the RFC); browsers might not do the same (perhaps indirectly) although I'd be surprised if NONE do. I would first try x509 -noout -subject|issuer -nameopt multiline,show_type and see if that helps. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate problem
On 7/6/2014 7:41 PM, Barbe, Charles wrote: Does anybody have any suggestions on where to look to figure this out? A tool to use? I realize that actually attaching the certa might be helpful but I do not have them handy as I write this. Please let me know if that might help somebody help me figure this out. Attaching the certs would be most helpful. Or, opening a ticket that includes them. Being unable to find the issuer for B but not A suggests that it's the Issuer field, or the IssuerKeyIdentifier; however, it's not guaranteed. (If only X.509 weren't so obtuse, if only PKIX weren't so tied to it, but they are.) -Kyle H smime.p7s Description: S/MIME Cryptographic Signature
RE: Certificate problem
You could try examining both PEM-encoded certificates using an ASN.1 decoder, such as the one here - http://lapo.it/asn1js -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Barbe, Charles Sent: Sunday, July 6, 2014 8:42 PM To: openssl-users@openssl.org Subject: Certificate problem I'm having a problem with generating certificates and I'm wondering if anybody has any suggestions on where to look. I have the following certificates and associated private keys: A - certificate A generated with one version of my software not using openssl B - certificate B generated with a new version of my software that does use openssl CA - a local certificate authority whose private key is used to sign both A and B I can verify both A and B using openssl verify using CA as the cafile argument. However, when I install CA on a client and try to connect a web browser to my server running the two different versions of software, they complain that they cannot find the issuer with A but not with B. I have examined both certificates and cannot find anything different about them. As far as I can tell, the only difference is that B used openssl to generate the certificate and A used our own custom software. The odd thing to me is that openssl verify can verify both just fine. What are the web browsers doing different? I've tried chrome, Firefox and opera and all behave the same... Accepting B and rejecting A. Does anybody have any suggestions on where to look to figure this out? A tool to use? I realize that actually attaching the certa might be helpful but I do not have them handy as I write this. Please let me know if that might help somebody help me figure this out. Thanks! Chad. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org smime.p7s Description: S/MIME cryptographic signature
Re: Certificate problem
I am positive that I am installing the ca in the correct spot because connections to server B correctly show the CA cert as the trusted root when I view the certificate for the connection in the web browser. To be clear, openssl verify says that both certificates A and B are ok when I provide my ca certificate as the CAfile argument. It is web browsers that do not find the issuer for certificate A. Ie, it seems to me like the browsers are MORE stringent in their checks than openssl verify. I will ask my management if I can attach the certs tomorrow... You and I know there is no risk attaching them but i still need the approval. Thanks for responding! CHAD On Jul 7, 2014, at 4:03 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Barbe, Charles Sent: Sunday, July 06, 2014 22:42 I have the following certificates and associated private keys: A - certificate A generated with one version of my software not using openssl B - certificate B generated with a new version of my software that does use openssl CA - a local certificate authority whose private key is used to sign both A and B I can verify both A and B using openssl verify using CA as the cafile argument. However, when I install CA on a client and try to connect a web browser to my server running the two different versions of software, they complain that they cannot find the issuer with A but not with B. I have examined both certificates and cannot find anything different about them. As far as I can tell, the only difference is that B used openssl to generate the certificate and A used our own custom software. The odd thing to me is that openssl verify can verify both just fine. What are the web browsers doing different? I've tried chrome, Firefox and opera and all behave the same... Accepting B and rejecting A. Does anybody have any suggestions on where to look to figure this out? A tool to use? You are installing in the correct placeS which can be different per browser, right? The only thing that springs to mind that could be invisible is string types and some options of the cert Issuer fields vs the CA Subject. RFC 5280 requires a fairly complicated Unicode-aware comparison algorithm which I believe openssl does (it definitely canonicalizes before comparison, but I haven't gone through the canonicalization to make sure it exactly matches the RFC); browsers might not do the same (perhaps indirectly) although I'd be surprised if NONE do. I would first try x509 -noout -subject|issuer -nameopt multiline,show_type and see if that helps. __ 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: Certificate problem
As I said in another note, I will try to send the certs tomorrow. Thanks for the help! CHAD On Jul 7, 2014, at 4:42 PM, Kyle Hamilton aerow...@gmail.com wrote: On 7/6/2014 7:41 PM, Barbe, Charles wrote: Does anybody have any suggestions on where to look to figure this out? A tool to use? I realize that actually attaching the certa might be helpful but I do not have them handy as I write this. Please let me know if that might help somebody help me figure this out. Attaching the certs would be most helpful. Or, opening a ticket that includes them. Being unable to find the issuer for B but not A suggests that it's the Issuer field, or the IssuerKeyIdentifier; however, it's not guaranteed. (If only X.509 weren't so obtuse, if only PKIX weren't so tied to it, but they are.) -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate problem
I will try an ASN.1 decoder tomorrow. Thanks for the suggestion! One thing I did try today was to have both servers generate their certificates using the same private key. Theoretically I would expect the two certs to then be exactly the same to the bit... I am not providing any domain or ip specific fields just so that I can do this comparison and made sure all other variable fields would be static. The only variable left should be my signing algorithm vs the one used my openssl's code. What I think I found was that the two certs were identical except for 4 bytes. There was a 0x05 and 0x00 following two fields in the open ssl generated cert. Each occurrence of these 2 bytes was following the signature algorithm identifier (in two places I think). These 4 bytes were not in the non-open ssl cert. could this be my problem? Is there a significance to the 0x05 and 0x00? They seemed to be part of the enclosing structure that contained the signature alg id but not part of the id itself. At least according to wireshark. Are they necessary padding that I'm missing in my custom cert generation? Like I said earlier, I'll try to attach the certs tomorrow. I really appreciate everybody's help! CHAD On Jul 7, 2014, at 5:09 PM, Ben Wilson b...@digicert.com wrote: You could try examining both PEM-encoded certificates using an ASN.1 decoder, such as the one here - http://lapo.it/asn1js -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Barbe, Charles Sent: Sunday, July 6, 2014 8:42 PM To: openssl-users@openssl.org Subject: Certificate problem I'm having a problem with generating certificates and I'm wondering if anybody has any suggestions on where to look. I have the following certificates and associated private keys: A - certificate A generated with one version of my software not using openssl B - certificate B generated with a new version of my software that does use openssl CA - a local certificate authority whose private key is used to sign both A and B I can verify both A and B using openssl verify using CA as the cafile argument. However, when I install CA on a client and try to connect a web browser to my server running the two different versions of software, they complain that they cannot find the issuer with A but not with B. I have examined both certificates and cannot find anything different about them. As far as I can tell, the only difference is that B used openssl to generate the certificate and A used our own custom software. The odd thing to me is that openssl verify can verify both just fine. What are the web browsers doing different? I've tried chrome, Firefox and opera and all behave the same... Accepting B and rejecting A. Does anybody have any suggestions on where to look to figure this out? A tool to use? I realize that actually attaching the certa might be helpful but I do not have them handy as I write this. Please let me know if that might help somebody help me figure this out. Thanks! Chad. __ 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: Certificate problem
From: owner-openssl-us...@openssl.org On Behalf Of Barbe, Charles Sent: Monday, July 07, 2014 21:59 I will try an ASN.1 decoder tomorrow. Thanks for the suggestion! One thing I did try today was to have both servers generate their certificates using the same private key. Theoretically I would expect the two certs to then be exactly the same to the bit... I am not providing any domain or ip specific fields just so that I can do this comparison and made sure all other variable fields would be static. The only variable left should be my signing If these certs are (intended to be) for the same server(s), then the server identity (usually name, rarely IP) can be the same, but it should not be omitted. SSL clients are supposed to, and at least browsers do, enforce it. Every cert should have a serial# which should be unique, and for real CA certs normally isn't even serial, it's random. OpenSSL still normally does serial. Did you do something to fake the serial, or did you ignore that (small) difference? algorithm vs the one used my openssl's code. What I think I found was that the two certs were identical except for 4 bytes. There was a 0x05 and 0x00 following two fields in the open ssl generated cert. Each occurrence of these 2 bytes was following the signature algorithm identifier (in two places I think). These 4 bytes were not in the non-open ssl cert. could this be my problem? Is there a significance to the 0x05 and 0x00? They seemed to be part of the enclosing structure that contained the signature alg id but not part of the id itself. At least according to wireshark. Are they necessary padding that I'm missing in my custom cert generation? They aren't necessary. Yes, the AlgorithmIdentifier occurs in two places; X.509 was designed in early days when there was great concern over the possibility of algorithm substitution attacks on publickey crypto as there historically had been on some symmetric crypto, so it occurs in the signed content (near the beginning) as well as after. The AlgorithmIdentifier is a general structure used in numerous places for numerous purposes. In some of these uses it includes 'parameters' which basically specialize the algorithm. In this use, the parameters are not needed, and ASN.1 allows two ways of handling this: the parameters can be omitted entirely, or they can be encoded as an ASN.1 NULL, which is the bytes 05 00. A robust parser/verifier should accept both. Like I said earlier, I'll try to attach the certs tomorrow. I really appreciate everybody's help! FYI ASN.1 decode can also be done by openssl commandline 'asn1parse', not as flexibly as some but it's already right to hand. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate problem
On Mon, Jul 7, 2014 at 9:59 PM, Barbe, Charles charles.ba...@allworx.com wrote: I will try an ASN.1 decoder tomorrow. Thanks for the suggestion! One thing I did try today was to have both servers generate their certificates using the same private key. Theoretically I would expect the two certs to then be exactly the same to the bit... I am not providing any domain or ip specific fields just so that I can do this comparison and made sure all other variable fields would be static. The serial numbers will likely be different. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate problem
CHAD On Jul 7, 2014, at 11:11 PM, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Jul 7, 2014 at 9:59 PM, Barbe, Charles charles.ba...@allworx.com wrote: I will try an ASN.1 decoder tomorrow. Thanks for the suggestion! One thing I did try today was to have both servers generate their certificates using the same private key. Theoretically I would expect the two certs to then be exactly the same to the bit... I am not providing any domain or ip specific fields just so that I can do this comparison and made sure all other variable fields would be static. The serial numbers will likely be different. I explicitly set the serial to 1 so I could do a binary compare of the certs. I'm beginning to think it could be my protocol implementation and not the cert itself. Jeff __ 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: Certificate problem
CHAD On Jul 7, 2014, at 11:03 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Barbe, Charles Sent: Monday, July 07, 2014 21:59 I will try an ASN.1 decoder tomorrow. Thanks for the suggestion! One thing I did try today was to have both servers generate their certificates using the same private key. Theoretically I would expect the two certs to then be exactly the same to the bit... I am not providing any domain or ip specific fields just so that I can do this comparison and made sure all other variable fields would be static. The only variable left should be my signing If these certs are (intended to be) for the same server(s), then the server identity (usually name, rarely IP) can be the same, but it should not be omitted. SSL clients are supposed to, and at least browsers do, enforce it. Yep I understand this. The removal of the name / ip was just for testing so I could do a binary compare of the two certs. Every cert should have a serial# which should be unique, and for real CA certs normally isn't even serial, it's random. OpenSSL still normally does serial. Did you do something to fake the serial, or did you ignore that (small) difference? In our case we're doing random but, again for my test only, I explicitly set it to 1. algorithm vs the one used my openssl's code. What I think I found was that the two certs were identical except for 4 bytes. There was a 0x05 and 0x00 following two fields in the open ssl generated cert. Each occurrence of these 2 bytes was following the signature algorithm identifier (in two places I think). These 4 bytes were not in the non-open ssl cert. could this be my problem? Is there a significance to the 0x05 and 0x00? They seemed to be part of the enclosing structure that contained the signature alg id but not part of the id itself. At least according to wireshark. Are they necessary padding that I'm missing in my custom cert generation? They aren't necessary. Yes, the AlgorithmIdentifier occurs in two places; X.509 was designed in early days when there was great concern over the possibility of algorithm substitution attacks on publickey crypto as there historically had been on some symmetric crypto, so it occurs in the signed content (near the beginning) as well as after. The AlgorithmIdentifier is a general structure used in numerous places for numerous purposes. In some of these uses it includes 'parameters' which basically specialize the algorithm. In this use, the parameters are not needed, and ASN.1 allows two ways of handling this: the parameters can be omitted entirely, or they can be encoded as an ASN.1 NULL, which is the bytes 05 00. A robust parser/verifier should accept both. This makes me think that my problem may be in our implementation of the protocol and not in the certificate itself. Thanks for the help! Like I said earlier, I'll try to attach the certs tomorrow. I really appreciate everybody's help! FYI ASN.1 decode can also be done by openssl commandline 'asn1parse', not as flexibly as some but it's already right to hand. __ 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: Certificate problem
On 7/7/2014 8:24 PM, Barbe, Charles wrote: CHAD On Jul 7, 2014, at 11:11 PM, Jeffrey Walton noloa...@gmail.com wrote: On Mon, Jul 7, 2014 at 9:59 PM, Barbe, Charles charles.ba...@allworx.com wrote: I will try an ASN.1 decoder tomorrow. Thanks for the suggestion! One thing I did try today was to have both servers generate their certificates using the same private key. Theoretically I would expect the two certs to then be exactly the same to the bit... I am not providing any domain or ip specific fields just so that I can do this comparison and made sure all other variable fields would be static. The serial numbers will likely be different. I explicitly set the serial to 1 so I could do a binary compare of the certs. I'm beginning to think it could be my protocol implementation and not the cert itself. Anything that uses NSS (Netscape Security Services, including Firefox and perhaps Chrome) is going to choke on this. They shouldn't have choked with that particular error you said, though, they should have said the certificate authority issued multiple certificates with the same serial number. -Kyle H smime.p7s Description: S/MIME Cryptographic Signature
Certificate problem
I'm having a problem with generating certificates and I'm wondering if anybody has any suggestions on where to look. I have the following certificates and associated private keys: A - certificate A generated with one version of my software not using openssl B - certificate B generated with a new version of my software that does use openssl CA - a local certificate authority whose private key is used to sign both A and B I can verify both A and B using openssl verify using CA as the cafile argument. However, when I install CA on a client and try to connect a web browser to my server running the two different versions of software, they complain that they cannot find the issuer with A but not with B. I have examined both certificates and cannot find anything different about them. As far as I can tell, the only difference is that B used openssl to generate the certificate and A used our own custom software. The odd thing to me is that openssl verify can verify both just fine. What are the web browsers doing different? I've tried chrome, Firefox and opera and all behave the same... Accepting B and rejecting A. Does anybody have any suggestions on where to look to figure this out? A tool to use? I realize that actually attaching the certa might be helpful but I do not have them handy as I write this. Please let me know if that might help somebody help me figure this out. Thanks! Chad. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
[FWD] I have a concatenate certificate problem
Forwarded to openssl-users for public discussion Best regards, Lutz - Forwarded message from liau ching huang [EMAIL PROTECTED] - DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.tw; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Conten t-Type:Message-ID; b=Snswhb6cHhWIpIwohcWO/AGTkUxIVfjWmmLWYNruDxPQz1FfdlSQSmBDxkOWIOaa4OQ2X4 hj1WBNqt27vy7MEtCLoxFrbRYEpWi75Vlrg0yfK8bjSR5xdO2xBjuPyNOUNUDQQKdUBRhCtv jicktufw/B8d2YzC+OYlcb3FCXvX4=; Date: Thu, 4 Dec 2008 16:17:30 +0800 (CST) From: liau ching huang [EMAIL PROTECTED] Subject: I have a concatenate certificate problem To: [EMAIL PROTECTED] Dear all: I have a concatenate certificate file including device certificate ,sub CA certificate , root CA certificate with PEM Format. I trace supplicant log ,then it shows that only sign the one certificate ( I think that it is the device certificate) and send to server. Then, server can not verify it. What I must call or modify OpenSSL function? Let it can work. Thanks. BR Loubot __ ???Yahoo!??2.0??? http://tw.mg0.mail.yahoo.com/dc/landing - End forwarded message - -- Lutz Jaenicke [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
CA.pl resign certificate problem
Hi, If I'd like to sign a certificate for a server for which I had previously signed a certificate with a different server key how can I do this from the same CA using the builtin CA.pl script? It has saved something about the first time that a cert was signed for server x and now just gives an error if I try and sign a new cert for the same FQDN, what do I need to clean out? Reason being, I have lost the original host and wish to create a new server, with new server key but using the original FQDN... thanks for any ideas, Andy. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Certificate problem on Windows XP client...
I have had to add certs to two different places in Windows in order for the them be found. I added them using system32/certmgr -- but that is not enough. I have found I also need to add them using the certificate control panel in Internet Explorer. I use certs to sign documents in OpenOffice among others. If you are finding that you cannot find certs you thought you had added, try adding them in both of these places. Lee Sergio wrote: Venkata LK Mula escribió: Hi, With reference to the above mentioned subject, we have generated root, server and client certificates in .pfx (p12) and .der format in FreeRADIUS using OpenSSL, installed these certificates on the Windows XP client. And when I'm trying to associate the Windows clinet to the network. it is displaying the message Windows was unable to find the certificate to log you on the network Roaming test2. Can any body lookinto the issue and suggest us with possible solutions for the same please. regards, Venkat If you are used freeradius utilities to issue certificates (make ca.pem, make server.pem, make client.pem, bootstrap command etc) you need to mark server certificate as CA:true or something like this, because is the server the issuer of client certs (at least, into default radius PKI). See and compare ca.cnf and server.cnf and you will see that default configuration doesn't put issuing permissions into server certificate, only into ca's. Because server hasn't got issuing permission, windows are considering that certification route is broken.You can see it into mozilla or ie. If you don't want use server certificate to sign client certs, you can issue them with ca.pem, changing only two options into the Makefile file (client.pem rule), or you can put your own commands. I have this configuration and it works perfectly, it's just a different PKI. But, if your client certs are now signed by the root authority and windows was unable to find it, i can't help you more :) Also, be sure that server and client certs have the correct extensions to work on XP. This extensions are KeyUsage and a list of numbers separated by points. Above commands, in this case, add this extensions. Hope this helps. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] -- Leonard F. Elia III, CISSP 757.864.5009 Sr. System Administrator ConITS - NASA Langley Research Center NCI Information Systems, Inc., Hampton VA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Certificate problem on Windows XP client...
Under most circumstances, roots certificates must be installed in the
Machine Root store, not in the User Root store. If you are looking to
authenticate to a wireless network, you may need to install the
certificate (and associated private key) to the Machine Certificates,
not the User Certificates. You can access this by running MMC.exe,
select File Add Ins..., click Add, select Certificate Manager,
select the store you want to interact with, hit OK, and then select
Add, Certificate Manager, and then the others, all in-turn. Once you
are done hit OK, and you should see all of your Certificate Manager
instances in the left of the window.
I hope this helps,
-Kyle H
On Mon, Aug 25, 2008 at 12:10 PM, Leonard F. Elia
[EMAIL PROTECTED] wrote:
I have had to add certs to two different places in Windows in order for the
them be found.
I added them using system32/certmgr -- but that is not enough. I have found
I also need to add them using the certificate control panel in Internet
Explorer. I use certs to sign documents in OpenOffice among others. If you
are finding that you cannot find certs you thought you had added, try adding
them in both of these places.
Lee
Sergio wrote:
Venkata LK Mula escribió:
Hi,
With reference to the above mentioned subject, we have generated root,
server and client certificates in .pfx (p12) and .der format in FreeRADIUS
using OpenSSL, installed these certificates on the Windows XP client. And
when I'm trying to associate the Windows clinet to the network. it is
displaying the message Windows was unable to find the certificate to log
you on the network Roaming test2. Can any body lookinto the issue and
suggest us with possible solutions for the same please.
regards,
Venkat
If you are used freeradius utilities to issue certificates (make ca.pem,
make server.pem, make client.pem, bootstrap command etc) you need to mark
server certificate as CA:true or something like this, because is the server
the issuer of client certs (at least, into default radius PKI). See and
compare ca.cnf and server.cnf and you will see that default configuration
doesn't put issuing permissions into server certificate, only into ca's.
Because server hasn't got issuing permission, windows are considering that
certification route is broken.You can see it into mozilla or ie.
If you don't want use server certificate to sign client certs, you can
issue them with ca.pem, changing only two options into the Makefile file
(client.pem rule), or you can put your own commands. I have this
configuration and it works perfectly, it's just a different PKI.
But, if your client certs are now signed by the root authority and windows
was unable to find it, i can't help you more :)
Also, be sure that server and client certs have the correct extensions to
work on XP. This extensions are KeyUsage and a list of numbers separated by
points. Above commands, in this case, add this extensions. Hope this helps.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
Leonard F. Elia III, CISSP 757.864.5009
Sr. System Administrator
ConITS - NASA Langley Research Center
NCI Information Systems, Inc., Hampton VA
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
Re: Certificate problem on Windows XP client...
Venkata LK Mula escribió: Hi, With reference to the above mentioned subject, we have generated root, server and client certificates in .pfx (p12) and .der format in FreeRADIUS using OpenSSL, installed these certificates on the Windows XP client. And when I'm trying to associate the Windows clinet to the network. it is displaying the message Windows was unable to find the certificate to log you on the network Roaming test2. Can any body lookinto the issue and suggest us with possible solutions for the same please. regards, Venkat If you are used freeradius utilities to issue certificates (make ca.pem, make server.pem, make client.pem, bootstrap command etc) you need to mark server certificate as CA:true or something like this, because is the server the issuer of client certs (at least, into default radius PKI). See and compare ca.cnf and server.cnf and you will see that default configuration doesn't put issuing permissions into server certificate, only into ca's. Because server hasn't got issuing permission, windows are considering that certification route is broken.You can see it into mozilla or ie. If you don't want use server certificate to sign client certs, you can issue them with ca.pem, changing only two options into the Makefile file (client.pem rule), or you can put your own commands. I have this configuration and it works perfectly, it's just a different PKI. But, if your client certs are now signed by the root authority and windows was unable to find it, i can't help you more :) Also, be sure that server and client certs have the correct extensions to work on XP. This extensions are KeyUsage and a list of numbers separated by points. Above commands, in this case, add this extensions. Hope this helps. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Newbie certificate problem (using PKCS#7 in Apache)
All, I have what is probably going to be an extremely newbie issue/question. I have a customer moving to us who uses Apache Tomcat with a PKCS#7 certificate and an accompanying .key file which looks rather foreign to me. Personally, i've never dealt with anything outside of the plain vanilla SSL certificates used in normal Apache. Is there a way to convert these files for use with normal Apache? Thanks, -- Jeffrey Lyon, President Level III Information Systems Technician [EMAIL PROTECTED] | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Talk for 4h 45m from the U.S. to Latin America for $10.00: http://www.defensecalling.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: cacert.pem selfsigned certificate problem
On Wed, Nov 24, 2004, Florin Angelescu wrote: On Tuesday 23 November 2004 16:57, Dr. Stephen Henson wrote: On Tue, Nov 23, 2004, Florin Angelescu wrote: Hello I am trying to set up an ssl acces to ldap following http://www.openldap.org/faq/data/cache/185.html i created my ca and signed the certificates for the server and client but i still get a 'self signed error' i checked and i saw that it was because of cacert.pem which is selfsigned question : how to solve this ??? (do i have to sign the CA certificate by another CA ? and how ? ) thank you very much Firstly I'd suggest you use CA.pl instead of CA.sh which is older. What is giving you the error? If its a client then you'd need to include a command line switch or configuration option telling it to include 'cacert.pem' in its trusted list of CAs. Steve. -- Thank you for answering. The error is given by ldapsearch ( and ldap.conf sldap.conf are well configured). The error is also reported by openssl. self signed certificate in certification chain (the CA certificate) The manual pages to ldapsearch don't include a command line option to add trusted CAs but it looks like there's a configuration file option in the system wide ldap.conf or the local .ldaprc file. I suggest you add an entry saying: TLS_CACERT /path/to/cacert.pem where /path/to/cacert.pem is wherever you've placed cacert.pem. 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: cacert.pem selfsigned certificate problem
On Wed, Nov 24, 2004, Florin Angelescu wrote: On Tuesday 23 November 2004 16:57, Dr. Stephen Henson wrote: On Tue, Nov 23, 2004, Florin Angelescu wrote: Hello I am trying to set up an ssl acces to ldap following http://www.openldap.org/faq/data/cache/185.html i created my ca and signed the certificates for the server and client but i still get a 'self signed error' i checked and i saw that it was because of cacert.pem which is selfsigned question : how to solve this ??? (do i have to sign the CA certificate by another CA ? and how ? ) thank you very much Firstly I'd suggest you use CA.pl instead of CA.sh which is older. What is giving you the error? If its a client then you'd need to include a command line switch or configuration option telling it to include 'cacert.pem' in its trusted list of CAs. Steve. -- Thank you for answering. The error is given by ldapsearch ( and ldap.conf sldap.conf are well configured). The error is also reported by openssl. self signed certificate in certification chain (the CA certificate) The problem is not that you have a self signed CA it is that the software doesn't trust it. The configuration or command line options should provide a means of specifying a file or directory containing trusted CAs. You should change them to include 'cacert.pem'. 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: cacert.pem selfsigned certificate problem
On Wednesday 24 November 2004 11:44, Dr. Stephen Henson wrote: On Wed, Nov 24, 2004, Florin Angelescu wrote: On Tuesday 23 November 2004 16:57, Dr. Stephen Henson wrote: On Tue, Nov 23, 2004, Florin Angelescu wrote: Hello I am trying to set up an ssl acces to ldap following http://www.openldap.org/faq/data/cache/185.html i created my ca and signed the certificates for the server and client but i still get a 'self signed error' i checked and i saw that it was because of cacert.pem which is selfsigned question : how to solve this ??? (do i have to sign the CA certificate by another CA ? and how ? ) thank you very much Firstly I'd suggest you use CA.pl instead of CA.sh which is older. What is giving you the error? If its a client then you'd need to include a command line switch or configuration option telling it to include 'cacert.pem' in its trusted list of CAs. Steve. -- Thank you for answering. The error is given by ldapsearch ( and ldap.conf sldap.conf are well configured). The error is also reported by openssl. self signed certificate in certification chain (the CA certificate) The problem is not that you have a self signed CA it is that the software doesn't trust it. The configuration or command line options should provide a means of specifying a file or directory containing trusted CAs. You should change them to include 'cacert.pem'. Steve. i used CA.pl -newcert i thought it does everything for me here is what i got ldap misc # openssl verify demoCA/cacert.pem demoCA/cacert.pem: /C=BE/ST=BEGLIUM/L=BRUSSELS/O=CAAMI_CA1/OU=CCI/CN=CAAMI_CA1/[EMAIL PROTECTED] error 18 at 0 depth lookup:self signed certificate OK __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cacert.pem selfsigned certificate problem
On Wed, Nov 24, 2004, Florin Angelescu wrote: On Wednesday 24 November 2004 11:44, Dr. Stephen Henson wrote: On Wed, Nov 24, 2004, Florin Angelescu wrote: On Tuesday 23 November 2004 16:57, Dr. Stephen Henson wrote: On Tue, Nov 23, 2004, Florin Angelescu wrote: Hello I am trying to set up an ssl acces to ldap following http://www.openldap.org/faq/data/cache/185.html i created my ca and signed the certificates for the server and client but i still get a 'self signed error' i checked and i saw that it was because of cacert.pem which is selfsigned question : how to solve this ??? (do i have to sign the CA certificate by another CA ? and how ? ) thank you very much Firstly I'd suggest you use CA.pl instead of CA.sh which is older. What is giving you the error? If its a client then you'd need to include a command line switch or configuration option telling it to include 'cacert.pem' in its trusted list of CAs. Steve. -- Thank you for answering. The error is given by ldapsearch ( and ldap.conf sldap.conf are well configured). The error is also reported by openssl. self signed certificate in certification chain (the CA certificate) The problem is not that you have a self signed CA it is that the software doesn't trust it. The configuration or command line options should provide a means of specifying a file or directory containing trusted CAs. You should change them to include 'cacert.pem'. Steve. i used CA.pl -newcert i thought it does everything for me here is what i got ldap misc # openssl verify demoCA/cacert.pem demoCA/cacert.pem: /C=BE/ST=BEGLIUM/L=BRUSSELS/O=CAAMI_CA1/OU=CCI/CN=CAAMI_CA1/[EMAIL PROTECTED] error 18 at 0 depth lookup:self signed certificate OK If you do: openssl verify -CAfile demoCA/cacert.pem demoCA/cacert.pem or openssl verify -CAfile demoCA/cacert.pem newcert.pem (or whatever the server certificate is called) it should the be OK. If OpenSSL just trusted any certificate created by CA.pl then anyone could create a certificate that your system would trust and that would be a rather large security hole. So you have to tell the OpenSSL applications which CAs they should trust. That's what the -CAfile command line option above is doing. 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]
cacert.pem selfsigned certificate problem
Hello I am trying to set up an ssl acces to ldap following http://www.openldap.org/faq/data/cache/185.html i created my ca and signed the certificates for the server and client but i still get a 'self signed error' i checked and i saw that it was because of cacert.pem which is selfsigned question : how to solve this ??? (do i have to sign the CA certificate by another CA ? and how ? ) thank you very much __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: cacert.pem selfsigned certificate problem
On Tue, Nov 23, 2004, Florin Angelescu wrote: Hello I am trying to set up an ssl acces to ldap following http://www.openldap.org/faq/data/cache/185.html i created my ca and signed the certificates for the server and client but i still get a 'self signed error' i checked and i saw that it was because of cacert.pem which is selfsigned question : how to solve this ??? (do i have to sign the CA certificate by another CA ? and how ? ) thank you very much Firstly I'd suggest you use CA.pl instead of CA.sh which is older. What is giving you the error? If its a client then you'd need to include a command line switch or configuration option telling it to include 'cacert.pem' in its trusted list of CAs. 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: cacert.pem selfsigned certificate problem
On Tuesday 23 November 2004 16:57, Dr. Stephen Henson wrote: On Tue, Nov 23, 2004, Florin Angelescu wrote: Hello I am trying to set up an ssl acces to ldap following http://www.openldap.org/faq/data/cache/185.html i created my ca and signed the certificates for the server and client but i still get a 'self signed error' i checked and i saw that it was because of cacert.pem which is selfsigned question : how to solve this ??? (do i have to sign the CA certificate by another CA ? and how ? ) thank you very much Firstly I'd suggest you use CA.pl instead of CA.sh which is older. What is giving you the error? If its a client then you'd need to include a command line switch or configuration option telling it to include 'cacert.pem' in its trusted list of CAs. Steve. -- Thank you for answering. The error is given by ldapsearch ( and ldap.conf sldap.conf are well configured). The error is also reported by openssl. self signed certificate in certification chain (the CA certificate) __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Client Certificate Problem
hi, i created a CA and a ClientKey witch i imported in my Client. in httpd.conf i configured Alias /test/ /opt/www/test/ Directory /opt/www/test/ Options Indexes Order allow,deny Allow from 192.168.0.142 SSLVerifyClient require SSLVerifyDepth 1 /Directory if i try to connect i get the following error. == ./logs/ssl_engine_log == [06/Jun/2002 13:04:06 01186] [info] Connection to child 5 established (server suse:443, client 192.168.0.142) [06/Jun/2002 13:04:06 01186] [info] Seeding PRNG with 23177 bytes of entropy [06/Jun/2002 13:04:06 01186] [info] Connection: Client IP: 192.168.0.142, Protocol: SSLv3, Cipher: EXP-RC4-MD5 (40/128 bits) [06/Jun/2002 13:04:06 01186] [info] Connection to child 5 closed with standard shutdown (server suse:443, client 192.168.0.142) == ./logs/access_log == 192.168.0.142 - - [06/Jun/2002:13:04:07 +0200] GET /test/ HTTP/1.1 403 265 == ./logs/error_log == [Thu Jun 6 13:04:07 2002] [error] mod_ssl: Re-negotiation handshake failed: Not accepted by client!? [Thu Jun 6 13:04:07 2002] [error] mod_ssl: SSL error on writing data (OpenSSL library error follows) [Thu Jun 6 13:04:07 2002] [error] OpenSSL: error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure == ./logs/ssl_engine_log == [06/Jun/2002 13:04:07 01187] [info] Connection to child 6 established (server suse:443, client 192.168.0.142) [06/Jun/2002 13:04:07 01187] [info] Seeding PRNG with 23177 bytes of entropy [06/Jun/2002 13:04:07 01187] [info] Connection: Client IP: 192.168.0.142, Protocol: SSLv3, Cipher: EXP-RC4-MD5 (40/128 bits) [06/Jun/2002 13:04:07 01187] [info] Initial (No.1) HTTPS request received for child 6 (server suse:443) [06/Jun/2002 13:04:07 01187] [info] Requesting connection re-negotiation [06/Jun/2002 13:04:07 01187] [info] Awaiting re-negotiation handshake [06/Jun/2002 13:04:07 01187] [error] Re-negotiation handshake failed: Not accepted by client!? [06/Jun/2002 13:04:07 01187] [error] SSL error on writing data (OpenSSL library error follows) [06/Jun/2002 13:04:07 01187] [error] OpenSSL: error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure [06/Jun/2002 13:04:07 01187] [info] Connection to child 6 closed with unclean shutdown (server suse:443, client 192.168.0.142) == ./logs/ssl_request_log == [06/Jun/2002:13:04:07 +0200] 192.168.0.142 SSLv3 (NONE) GET /test/ HTTP/1.1 265 == ./logs/access_log == 192.168.0.142 - - [06/Jun/2002:13:04:09 +0200] GET /test/ HTTP/1.1 403 265 == ./logs/error_log == [Thu Jun 6 13:04:09 2002] [error] mod_ssl: Certificate Verification: Error (20): unable to get local issuer certificate [Thu Jun 6 13:04:09 2002] [error] mod_ssl: Re-negotiation handshake failed: Not accepted by client!? [Thu Jun 6 13:04:09 2002] [error] mod_ssl: Certificate Verification: Error (20): unable to get local issuer certificate [Thu Jun 6 13:04:09 2002] [error] mod_ssl: SSL error on writing data (OpenSSL library error follows) [Thu Jun 6 13:04:09 2002] [error] OpenSSL: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned == ./logs/ssl_engine_log == [06/Jun/2002 13:04:09 01188] [info] Connection to child 7 established (server suse:443, client 192.168.0.142) [06/Jun/2002 13:04:09 01188] [info] Seeding PRNG with 23177 bytes of entropy [06/Jun/2002 13:04:09 01188] [info] Connection: Client IP: 192.168.0.142, Protocol: SSLv3, Cipher: EXP-RC4-MD5 (40/128 bits) [06/Jun/2002 13:04:09 01188] [info] Initial (No.1) HTTPS request received for child 7 (server suse:443) [06/Jun/2002 13:04:09 01188] [info] Requesting connection re-negotiation [06/Jun/2002 13:04:09 01188] [info] Awaiting re-negotiation handshake [06/Jun/2002 13:04:09 01188] [error] Certificate Verification: Error (20): unable to get local issuer certificate [06/Jun/2002 13:04:09 01188] [error] Re-negotiation handshake failed: Not accepted by client!? [06/Jun/2002 13:04:09 01188] [error] Certificate Verification: Error (20): unable to get local issuer certificate [06/Jun/2002 13:04:09 01188] [error] SSL error on writing data (OpenSSL library error follows) [06/Jun/2002 13:04:09 01188] [error] OpenSSL: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned [06/Jun/2002 13:04:09 01188] [info] Connection to child 7 closed with unclean shutdown (server suse:443, client 192.168.0.142) == ./logs/ssl_request_log == [06/Jun/2002:13:04:09 +0200] 192.168.0.142 SSLv3 (NONE) GET /test/ HTTP/1.1 265 thx for help Jochen __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Certificate problem
I am not able to create a server certificate that is recognized by Netscape. The error I am encountering is "The Certificate is not valid for the attempted application. I have scoured google but have not found the correct way to overcome this error. Here is what I have done.
Created selfsigned CA with CA.sh -newca
generated server cert request in IIS and saved to file.
ran openssl ca -policy policy_anything -out servercert.pem -config openssl.cnf -in certreq.txt
I installed this file back into IIS and get the above error when attempting to access with Netscape.
Here is my openssl.cnf . I believe this may have to do with the V3_extensions but I am not sure.
If anyone has any pointers I would appreciate it.
Myke
## OpenSSL example configuration file.# This is mostly being used for generation of certificate requests.## This definition stops the following lines choking if HOME isn't# defined.HOME = .RANDFILE = $ENV::HOME/.rnd# Extra OBJECT IDENTIFIER info:#oid_file = $ENV::HOME/.oidoid_section = new_oids# To use this configuration file with the "-extfile" option of the# "openssl x509" utility, name here the section containing the# X.509v3 extensions to use:# extensions = # (A!
lternatively, use a configuration file that has only# X.509v3 extensions in its main [= default] section.)[ new_oids ]# We can add new OIDs in here for use by 'ca' and 'req'.# Add a simple OID like this:# testoid1=1.2.3.4# Or use config file substitution like this:# testoid2=${testoid1}.5.6[ ca ]default_ca = CA_default # The default ca section[ CA_default ]dir = /usr/local/ssl/misc/myCA # Where everything is keptcerts = $dir/certs!
bsp; # Where the issue
d certs are keptcrl_dir = $dir/crl # Where the issued crl are keptdatabase = $dir/index.txt # database index file.new_certs_dir = $dir/newcerts # default place for new certs.certificate = $dir/cacert.pem # The CA certificateserial = $dir/serial # The current serial numbercrl = $dir/crl.pem # The current CRLprivate_key = $dir/private/cakey.pem# The private!
keyRANDFILE = $dir/private/.rand # private random number filex509_extensions = usr_cert # The extentions to add to the cert# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs# so this is commented out by default to leave a V1 CRL.# crl_extensions = crl_extdefault_days =365 # how long to certify fordefault_crl_days= 30 # how long before next CRLdefault_md = md5!
; # which md to use.preserve
bsp; = no # keep passed DN ordering# A few difference way of specifying how similar the request should look# For type CA, the listed attributes must be the same, and the optional# and supplied fields are just that :-)policy = policy_match# For the CA policy[ policy_match ]countryName = matchstateOrProvinceName = matchorganizationName = matchorganizationalUnitName = optionalcommonName = suppliedemailAddress = optional# For the 'anything' poli!
cy# At this point in time, you must list all acceptable 'object'# types.[ policy_anything ]countryName = optionalstateOrProvinceName = optionallocalityName = optionalorganizationName = optionalorganizationalUnitName = optionalcommonName = suppliedemailAddress = optional[ req ]default_bits = 1024default_keyfile = privkey.pemdistinguished_name = req_di!
stinguished_nameattributes
p; = req_attributesx509_extensions = v3_ca # The extentions to add to the self signed cert# Passwords for private keys if not present they will be prompted for# input_password = secret# output_password = secret# This sets a mask for permitted string types. There are several options. # default: PrintableString, T61String, BMPString.# pkix : PrintableString, BMPString.# utf8only: only UTF8Strings.# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).# MASK: a literal mask value.# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings# so use this option with caution!string_mask = nombstrreq_extensions = v3_req # The extensions to add to a certificate request[ req_distinguished_name ]countryName!
bsp; = Country Name (2 letter code)countryName_default = UScountryName_min = 2countryName_max = 2stateOrProvinceName = State or Province Name (full name)stateOrProvinceName_default = Some-StatelocalityName = Locality Name (eg, city)0.organizationName = Organization Name (eg, company)0.organizationName_default = Internet Widg!
its Pty Ltd# we can do this but it is not needed normall
y :-)#1.organizationName = Second Organization Name (eg, company)#1.organizationName_default = World Wide Web Pty LtdorganizationalUnitName = Organizational Unit Name (eg, section)#organizationalUnitName_default =commonName = Common Name (eg, YOUR name)commonName_max = 64emailAddress = Email AddressemailAddress_max = 40# SET-ex3&!
nbsp; = SET extension number 3[ req_attributes
Re: Certificate Problem :)
Hello, AFAIK by default client does not sends its certificate. You should do something like this: SSL_CTX_set_verify(context, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, 0); Maybe this should help. Regards Ales Privetivy Dear fellow developers, I am experiencing some problems with a product we released. We rely on a public/private key architecture. The client connects to our server and we check to see if the certificate the client had was signed by us. I do this by checking to see if I can even get a client certificate. From my understanding if the client does not have a trusted certificate signed by the same CA as the server or by a trusted CA the server will not receive the certificate ( from the applications point of view). I do a SSL_get_peer_certificate and everything works for a while. But all of a sudden I never get a certificate from the client. This causes our server to think the client isn't validated. The only way we seem to be able to fix this is to re-create all new certificates. The certificates are set to expire in a year but the problem occurs within weeks/months of deployment and continues to happen. Does anyone have any insight on how this could be happening? Thank you for your time. - Andrew T. Finnell Software Engineer eSecurity Inc (321) 394-2485 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Certificate Problem / get_peer_certificate + ssldump
) Handshake 1 12 2.2465 (0.0017) CSV3.1(103) application_data 1 13 2.2474 (0.0008) SCV3.1(40) application_data 1 14 2.2485 (0.0010) CSV3.1(159) application_data 1 15 2.2500 (0.0014) SCV3.1(52) application_data 1 16 2.2508 (0.0008) SCV3.1(5200) application_data download: 1 26 73.8719 (0.0414) CSV3.1(115) Handshake 1 27 73.8729 (0.0009) SCV3.1(94) Handshake 1 28 73.9787 (0.1058) SCV3.1(1864) Handshake 1 29 73.9789 (0.0002) SCV3.1(336) Handshake 1 30 73.9789 (0.) SCV3.1(35) Handshake 1 31 74.0222 (0.0433) CSV3.1(954) Handshake 1 32 74.0234 (0.0011) SCV3.1(22) Alert 174.0244 (0.0009) SC TCP FIN 1 33 74.0255 (0.0011) CSV3.1(154) Handshake 1 34 74.0255 (0.) CSV3.1(73) Handshake 1 35 74.0255 (0.) CSV3.1(21) ChangeCipherSpec 1 36 74.0255 (0.) CSV3.1(36) Handshake 174.0256 (0.0001) CS TCP FIN - Andrew T. Finnell Active Solutions L.L.C [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Eric Rescorla Sent: Monday, April 22, 2002 12:36 PM To: [EMAIL PROTECTED] Subject: Re: Certificate Problem / get_peer_certificate Andrew T. Finnell [EMAIL PROTECTED] writes: I do not know. I do not have access to these machines they are at our client's location. I suppose we could try and get them to install ssldump and run it. Although I am not sure this is an option. ssldump can read data captured with 'tcpdump -s 8192 -w' if that helps at all. In general, this sort of thing is very difficult to diagnose without either ssldump traces or OpenSSL logging info. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ __ 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]
Certificate Problem :)
Title: Certificate Problem :) Dear fellow developers, I am experiencing some problems with a product we released. We rely on a public/private key architecture. The client connects to our server and we check to see if the certificate the client had was signed by us. I do this by checking to see if I can even get a client certificate. From my understanding if the client does not have a trusted certificate signed by the same CA as the server or by a trusted CA the server will not receive the certificate ( from the applications point of view). I do a SSL_get_peer_certificate and everything works for a while. But all of a sudden I never get a certificate from the client. This causes our server to think the client isn't validated. The only way we seem to be able to fix this is to re-create all new certificates. The certificates are set to expire in a year but the problem occurs within weeks/months of deployment and continues to happen. Does anyone have any insight on how this could be happening? Thank you for your time. - Andrew T. Finnell Software Engineer eSecurity Inc (321) 394-2485
Re: Certificate Problem :)
On Mon, 22 Apr 2002, Andrew Finnell wrote: Dear fellow developers, I am experiencing some problems with a product we released. We rely on a public/private key architecture. The client connects to our server and we check to see if the certificate the client had was signed by us. I do this by checking to see if I can even get a client certificate. From my understanding if the client does not have a trusted certificate signed by the same CA as the server or by a trusted CA the server will not receive the certificate ( from the applications point of view). I do a SSL_get_peer_certificate and everything works for a while. But all of a sudden I never get a certificate from the client. This causes our server to think the client isn't validated. The only way we seem to be able to fix this is to re-create all new certificates. The certificates are set to expire in a year but the problem occurs within weeks/months of deployment and continues to happen. Does anyone have any insight on how this could be happening? Thank you for your time. what type of connection do you speak of? https or ssh? and what platform you are running on? - Andrew T. Finnell Software Engineer eSecurity Inc (321) 394-2485 -- snail-mail : Michal Bachorik Nedozerskeho 207 Nedozery 972 12 SLOVAKIA phone : +421 862 54 85 220 e-mail : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Certificate Problem / get_peer_certificate
I am reposting this with a different account. Hopefully my pervious email didn't get sent to a lot of people. I have no control over HTML being put in my other account's email as the Exchange server does this automatically. Sorry. Dear fellow developers, I am experiencing some problems with a product we released. We rely on a public/private key architecture. The client connects to our server and we check to see if the certificate the client had was signed by us. I do this by checking to see if I can even get a client certificate. From my understanding if the client does not have a trusted certificate signed by the same CA as the server or by a trusted CA the server will not receive the certificate ( from the applications point of view). I do a SSL_get_peer_certificate and everything works for a while. But all of a sudden I never get a certificate from the client. This causes our server to think the client isn't validated. The only way we seem to be able to fix this is to re-create all new certificates. The certificates are set to expire in a year but the problem occurs within weeks/months of deployment and continues to happen. Does anyone have any insight on how this could be happening? Thank you for your time. - Andrew T. Finnell Active Solutions L.L.C [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Certificate Problem :)
Michal, This is using the OpenSSL libraries through TCP/IP communications. More specifically, it is through the use of SSLIOP (CORBA). This happens on all Win32 machines - Solaris 6/7. And Win32 - Win32. - Andrew T. Finnell Active Solutions L.L.C [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Michal Bachorik Sent: Monday, April 22, 2002 12:08 PM To: Openssl ([EMAIL PROTECTED]) Subject: Re: Certificate Problem :) On Mon, 22 Apr 2002, Andrew Finnell wrote: Dear fellow developers, I am experiencing some problems with a product we released. We rely on a public/private key architecture. The client connects to our server and we check to see if the certificate the client had was signed by us. I do this by checking to see if I can even get a client certificate. From my understanding if the client does not have a trusted certificate signed by the same CA as the server or by a trusted CA the server will not receive the certificate ( from the applications point of view). I do a SSL_get_peer_certificate and everything works for a while. But all of a sudden I never get a certificate from the client. This causes our server to think the client isn't validated. The only way we seem to be able to fix this is to re-create all new certificates. The certificates are set to expire in a year but the problem occurs within weeks/months of deployment and continues to happen. Does anyone have any insight on how this could be happening? Thank you for your time. what type of connection do you speak of? https or ssh? and what platform you are running on? - Andrew T. Finnell Software Engineer eSecurity Inc (321) 394-2485 -- snail-mail : Michal Bachorik Nedozerskeho 207 Nedozery 972 12 SLOVAKIA phone : +421 862 54 85 220 e-mail : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] __ 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: Certificate Problem / get_peer_certificate
Andrew T. Finnell [EMAIL PROTECTED] writes: I do a SSL_get_peer_certificate and everything works for a while. But all of a sudden I never get a certificate from the client. This causes our server to think the client isn't validated. The only way we seem to be able to fix this is to re-create all new certificates. The certificates are set to expire in a year but the problem occurs within weeks/months of deployment and continues to happen. Does anyone have any insight on how this could be happening? Thank you for your time. What does ssldump say? -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Certificate Problem / get_peer_certificate
Eric, I do not know. I do not have access to these machines they are at our client's location. I suppose we could try and get them to install ssldump and run it. Although I am not sure this is an option. - Andrew T. Finnell Active Solutions L.L.C [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Eric Rescorla Sent: Monday, April 22, 2002 12:25 PM To: [EMAIL PROTECTED] Subject: Re: Certificate Problem / get_peer_certificate Andrew T. Finnell [EMAIL PROTECTED] writes: I do a SSL_get_peer_certificate and everything works for a while. But all of a sudden I never get a certificate from the client. This causes our server to think the client isn't validated. The only way we seem to be able to fix this is to re-create all new certificates. The certificates are set to expire in a year but the problem occurs within weeks/months of deployment and continues to happen. Does anyone have any insight on how this could be happening? Thank you for your time. What does ssldump say? -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ __ 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: Certificate Problem / get_peer_certificate
Andrew T. Finnell [EMAIL PROTECTED] writes: I do not know. I do not have access to these machines they are at our client's location. I suppose we could try and get them to install ssldump and run it. Although I am not sure this is an option. ssldump can read data captured with 'tcpdump -s 8192 -w' if that helps at all. In general, this sort of thing is very difficult to diagnose without either ssldump traces or OpenSSL logging info. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]] http://www.rtfm.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
certificate problem? key size problem? help!!!
I am trying to generate a slient program will SSLeary and openssl. I seem to be able to connect to the server and send the authorization (basic is required) with problems but the certificate is never trusted, nor can I get the index html page. Instead I get insufficient key size html document. I've tried setting the cipher to all possible ssl2 ciphers to no avail. I need to use -ssl2 or the connect never completes successfully. I compile OpenSSL 0.9.6c 21 dec 2001 and rans all test successfull on a sparc 5 solaris 2.7 with gcc 3.x . Is the certificate verify stopping a successful connection? Thanks, any help is appreciated. Mark A transcript is the following: bash-2.05$ openssl s_client -connect autonet.va.autometric.com:443 -ssl2 CONNECTED(0004) depth=0 /C=US/ST=Virginia/L=Springfield/O=Autometric Inc./OU=Information Technology Services/OU=Terms of use at www.ver isign.com/rpa (c)00/CN=autonet.va.autometric.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=US/ST=Virginia/L=Springfield/O=Autometric Inc./OU=Information Technology Services/OU=Terms of use at www.ver isign.com/rpa (c)00/CN=autonet.va.autometric.com verify error:num=27:certificate not trusted verify return:1 depth=0 /C=US/ST=Virginia/L=Springfield/O=Autometric Inc./OU=Information Technology Services/OU=Terms of use at www.ver isign.com/rpa (c)00/CN=autonet.va.autometric.com verify error:num=21:unable to verify the first certificate verify return:1 --- Server certificate -BEGIN CERTIFICATE- MIIFvjCCBSegAwIBAgIQHUCKzBkocA6UrDiJo19R7TANBgkqhkiG9w0BAQQFADCB ujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVy aVNpZ24sIEluYy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2Vy dmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMg SW5jb3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjAeFw0w MTA1MDQwMDAwMDBaFw0wMjA1MzEyMzU5NTlaMIHTMQswCQYDVQQGEwJVUzERMA8G A1UECBMIVmlyZ2luaWExFDASBgNVBAcUC1NwcmluZ2ZpZWxkMRgwFgYDVQQKFA9B dXRvbWV0cmljIEluYy4xKDAmBgNVBAsUH0luZm9ybWF0aW9uIFRlY2hub2xvZ3kg U2VydmljZXMxMzAxBgNVBAsUKlRlcm1zIG9mIHVzZSBhdCB3d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwMDEiMCAGA1UEAxQZYXV0b25ldC52YS5hdXRvbWV0cmljLmNv bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAm9mjObk6Zgb10TycoACI0XiS u0gXoGgfdkwh1t3ipk63sZZHmclg7LILLqsg8U/yzeWi67KR+74ytAfIWj1Zgh/S RBxTIhrC0uv9hK82+acT6stalQKZ7plxpLAP/ahCxOOEmyfU8Iz8+n3DlATjbzQb BGZsfir1UjnQwV3vJvcCAwEAAaOCAqgwggKkMAkGA1UdEwQCMAAwggIfBgNVHQME ggIWMIICEjCCAg4wggIKBgtghkgBhvhFAQcBATCCAfkWggGnVGhpcyBjZXJ0aWZp Y2F0ZSBpbmNvcnBvcmF0ZXMgYnkgcmVmZXJlbmNlLCBhbmQgaXRzIHVzZSBpcyBz dHJpY3RseSBzdWJqZWN0IHRvLCB0aGUgVmVyaVNpZ24gQ2VydGlmaWNhdGlvbiBQ cmFjdGljZSBTdGF0ZW1lbnQgKENQUyksIGF2YWlsYWJsZSBhdDogaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzsgYnkgRS1tYWlsIGF0IENQUy1yZXF1ZXN0c0B2 ZXJpc2lnbi5jb207IG9yIGJ5IG1haWwgYXQgVmVyaVNpZ24sIEluYy4sIDI1OTMg Q29hc3QgQXZlLiwgTW91bnRhaW4gVmlldywgQ0EgOTQwNDMgVVNBIFRlbC4gKzEg KDQxNSkgOTYxLTg4MzAgQ29weXJpZ2h0IChjKSAxOTk2IFZlcmlTaWduLCBJbmMu ICBBbGwgUmlnaHRzIFJlc2VydmVkLiBDRVJUQUlOIFdBUlJBTlRJRVMgRElTQ0xB SU1FRCBhbmQgTElBQklMSVRZIExJTUlURUQuoA4GDGCGSAGG+EUBBwEBAaEOBgxg hkgBhvhFAQcBAQIwLDAqFihodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9DUFMgMBEGCWCGSAGG+EIBAQQEAwIGQDAUBgNVHSUEDTALBglghkgBhvhC BAEwMAYKYIZIAYb4RQEGBwQiFiA2MTA4ZDEzZWQ0YWY5Mzc2ZmNmN2E4NjU5MTUy MTk1MzAZBgpghkgBhvhFAQYPBAsWCTA4MzY1NDYxNjANBgkqhkiG9w0BAQQFAAOB gQA95wRAkoblU4HNDEsX2yEexGOedbYARoz1YlazpjliC6T+KpZYkxJMxhBif40h Q1/ojzNPqxS1kcd77hdUJUD1CWb6Es0N6xpeTVCVb791Dh9irxRbuB+DbAdXZIeP qIW4TiR5ZheXD1TZ6RieNeNFC3dDxdRUJnQSSj4qVuLmwg== -END CERTIFICATE- subject=/C=US/ST=Virginia/L=Springfield/O=Autometric Inc./OU=Information Technology Services/OU=Terms of use at www.ver isign.com/rpa (c)00/CN=autonet.va.autometric.com issuer=/O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CP S Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign --- No client certificate CA names sent --- Ciphers common between both SSL endpoints: RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5 EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5 --- SSL handshake has read 1607 bytes and written 242 bytes --- New, SSLv2, Cipher is DES-CBC3-MD5 Server public key is 1024 bit SSL-Session: Protocol : SSLv2 Cipher: DES-CBC3-MD5 Session-ID: 06777312619B9ADE05EAABB9E2AA6C15 Session-ID-ctx: Master-Key: F56EAFF8608CD7D6BD57F309FF7E51672D7D16CF1D8E6A2A Key-Arg : BE8453F63ACB1BC9 Start Time: 1011372100 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- GET / HTTP/1.0 Authorization: Basic removed for security considerations= HTTP/1.0 403 Forbidden Proxy-agent: Netscape-Proxy/3.52 Date: Fri, 18 Jan 2002 16:45:44 GMT Content-type: text/html titleInsufficient encryption/titleh1Insufficient encryption/h1 This document requires a larger secret key size for encryption than your browser is capable of supporting. HTMLHEADTITLEForbidden/TITLE/HEAD BODYH1Forbidden/H1 The proxy's access
Re: certificate problem
Thanks for the advice. I was able to get an alternate /dev/urandom package working. Soo On Wed, 28 Nov 2001, Lutz Jaenicke wrote: On Wed, Nov 28, 2001 at 08:47:13AM +0100, [EMAIL PROTECTED] wrote: Solaris does not support the device /dev/urandom which is necessary to seed the PRNG by default. You can either install a package which emulate /dev/urandom or seed the PRNG manually by the following commands : unsigned char seed_buffer [1024] ; RAND_pseudo_byte(seed_buffer, 1024) ; RAND_seed(seed_buffer, 1024) ; ... RSA_generate_key(...) This, with all due respect, is no good advice. Depending on the platform (and maybe even compiler settings), the buffer may be memset to 0. Generating pseudo bytes from it will mix in the PID and have the pool mixed. That might look random, but finally (if somebody finds out your method), the generated keys are weak. I strongly suggest using using one of the alternative PRNG sources described in the FAQ. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ 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: certificate problem
On Wed, Nov 28, 2001 at 08:47:13AM +0100, [EMAIL PROTECTED] wrote: Solaris does not support the device /dev/urandom which is necessary to seed the PRNG by default. You can either install a package which emulate /dev/urandom or seed the PRNG manually by the following commands : unsigned char seed_buffer [1024] ; RAND_pseudo_byte(seed_buffer, 1024) ; RAND_seed(seed_buffer, 1024) ; ... RSA_generate_key(...) This, with all due respect, is no good advice. Depending on the platform (and maybe even compiler settings), the buffer may be memset to 0. Generating pseudo bytes from it will mix in the PID and have the pool mixed. That might look random, but finally (if somebody finds out your method), the generated keys are weak. I strongly suggest using using one of the alternative PRNG sources described in the FAQ. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: certificate problem
Title: RE: certificate problem Lutz, Well sometimes installing additional software is not acceptable as was in my case. Do you have any other suggesstions for people like me? We ship a product that uses OpenSSL and we don't want to install 3rd party apps. While Soo Hom just wants to create certificates with the openssl tool, what would you suggest be done if programatically to generate random bytes if we cannot install a PRNG emulation package? Thanks. - Andrew -Original Message- From: Lutz Jaenicke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 28, 2001 5:27 AM To: [EMAIL PROTECTED] Subject: Re: certificate problem On Wed, Nov 28, 2001 at 08:47:13AM +0100, [EMAIL PROTECTED] wrote: Solaris does not support the device /dev/urandom which is necessary to seed the PRNG by default. You can either install a package which emulate /dev/urandom or seed the PRNG manually by the following commands : unsigned char seed_buffer [1024] ; RAND_pseudo_byte(seed_buffer, 1024) ; RAND_seed(seed_buffer, 1024) ; ... RSA_generate_key(...) This, with all due respect, is no good advice. Depending on the platform (and maybe even compiler settings), the buffer may be memset to 0. Generating pseudo bytes from it will mix in the PID and have the pool mixed. That might look random, but finally (if somebody finds out your method), the generated keys are weak. I strongly suggest using using one of the alternative PRNG sources described in the FAQ. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] BTU Cottbus http://www.aet.TU- Cottbus.DE/personen/jaenicke/ Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129 Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153 __ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: certificate problem
Hi, Solaris does not support the device /dev/urandom which is necessary to seed the PRNG by default. You can either install a package which emulate /dev/urandom or seed the PRNG manually by the following commands : unsigned char seed_buffer [1024] ; RAND_pseudo_byte(seed_buffer, 1024) ; RAND_seed(seed_buffer, 1024) ; ... RSA_generate_key(...) Best Regards, Guido Frohn UTIMACO SAFEWARE AG Chief Development Engineer Tel. +49 (0)241 1696 485 Fax. +49 (0)241 1696 109 mailto:[EMAIL PROTECTED] Internet http://www.utimaco.de Germanusstraße 4 D-52080 Aachen Germany Soo Hom [EMAIL PROTECTED]To: [EMAIL PROTECTED] Sent by:cc: owner-openssl-users@o Subject: certificate problem penssl.org 27.11.01 22:07 Please respond to openssl-users Hello, I have an ultrasparc 2 running solaris 8. When attempting to make a certificate I get this error: # openssl req -new new.cert.csr Using configuration from /usr/local/ssl/openssl.cnf unable to load 'random state' This means that the random number generator has not been seeded with much random data. Generating a 1024 bit RSA private key 25525:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:md_rand.c:492:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html 25525:error:04069003:rsa routines:RSA_generate_key:BN lib:rsa_gen.c:182: Any ideas on how to fix this problem? Soo __ 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]
Certificate Problem with Sendmail
Folks, I'm evaluating the use of Sendmail with TLS for a client. I'm using Sendmail 8.11.6 and openssl 0.9.6b, running under Solaris 2.6 I've created a CA, and a server certificate, apparently successfully. When I try and start Sendmail using these, though, I get the following errors in the log: Sep 27 09:26:37 cs72 sendmail[3719]: TLS: error: srv: SSL_CTX_use_PrivateKey_file(/usr/local/CA/private/CAkey.pem) failed Sep 27 09:26:37 cs72 sendmail[3719]: TLS: 3719:error:0906406D:PEM routines:DEF_CALLBACK:problems getting password:pem_lib.c:114: Sep 27 09:26:37 cs72 sendmail[3719]: TLS: 3719:error:0906A068:PEM routines:PEM_do_header:bad password read:pem_lib.c:430: Sep 27 09:26:37 cs72 sendmail[3719]: TLS: 3719:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:missing asn1 eos:ssl_rsa.c:707: I'm still learning my way round Openssl, so this is probably a novice type error - maybe even an FAQ (though I couldn't see anything there that looked like this) So I need some advice as to what I might have done wrong, please TIA, Dave __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Is this a certificate problem?
Terry,
It is not a problem with your certificates, it is a problem with the
server certificates. It would be hard to guess what the problem might be
without more information. It could be as simple as your failing to provide
OpenSSL with a set of trusted root certificates. If you want to bypass
authentication JUST FOR TESTING PURPOSES, you can do so by calling
SSL_CTX_set_verify(ctx, SSL_VERIFY_NONE). But note that any connections made
are not authenticated, but they are enrcrypted.
_
Greg Stark
Ethentica, Inc.
[EMAIL PROTECTED]
_
- Original Message -
From: "Terry Bird" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 25, 2001 9:10 PM
Subject: Is this a certificate problem?
Hi,
Im new to SSL and Im having trouble with RC4-128 encrypted sites. Im
hoping
that its just be a problem with my certificates. If I force it to bypass
this code its okay:
i=ssl_verify_cert_chain(s,sk);
if ((s-verify_mode != SSL_VERIFY_NONE) (!i))
{
al=ssl_verify_alarm_type(s-verify_result);
SSLerr(SSL_F_SSL3_GET_SERVER_CERTIFICATE,SSL_R_CERTIFICATE_VERIFY_FAILED);
goto f_err;
}
This code is in the function ssl3_get_server_certificate(), in the file
s3_clnt.c.
So, does this look like a certificate problem?
Thanks for any help.
Terry
__
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]
Is this a certificate problem?
Hi,
Im new to SSL and Im having trouble with RC4-128 encrypted sites. Im hoping
that its just be a problem with my certificates. If I force it to bypass
this code its okay:
i=ssl_verify_cert_chain(s,sk);
if ((s-verify_mode != SSL_VERIFY_NONE) (!i))
{
al=ssl_verify_alarm_type(s-verify_result);
SSLerr(SSL_F_SSL3_GET_SERVER_CERTIFICATE,SSL_R_CERTIFICATE_VERIFY_FAILED);
goto f_err;
}
This code is in the function ssl3_get_server_certificate(), in the file
s3_clnt.c.
So, does this look like a certificate problem?
Thanks for any help.
Terry
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Nescape certificate Problem
Hi, I have a question on the Nescape certificate. I've signed the SPKI request from Netscape and then I put the signed certificate back to the client browser.However, I found that there is a problem in verifying this certificate in Netscape browser. When I click "Verify" button in Netscape browser(security section), an error occurred: "Certificate Signature Invalid". I am sure that I've installed the CA root certificate properly as there is no error in verifying CA root certificate in Netscape. Then, I've exported the "installed certificate" to .p12 file from Netscape browser and then I installed the .p12 file into IE browser. I found that this time everything goes fine. That is, IE can recognize my certificate properly. I wonder if there is a trick in generating client certificate for fitting Netscape browser. Many Thks for your help Best regards, Peter __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Importing Certificate Problem.
I don't know what CA.pl -pkcs12 does nor what it does expect. Anyway, if you simply need to create a PKCS12 file to import in netscape you need at least the file containing the private key (say for example newkey.pem) and the one with your certificate (say newcert.pem). If you also have your CA certificate file in, say, cacert.pem you can put in one PKCS12 file altogether by doing: $openssl pkcs12 -export -out mycerts.p12 -in newcert.pem -inkey newkey.pem -certfile cacert.pem you will be asked for the private key encryption passphrase first, and then for a new passphrase to protect the PKCS12 package. It will create the file mycerts.p12 containing all the things you need. Switch to netscape and import everything selecting mycerts.p12. You will be asked the passphrase protecting the package and the one protecting netscape's key repository, I don't remember in whitch order at the moment, pay attention to message boxes title. Netscape will import your certificate and private key and, more, your CA certificate. Remember to grant rights to your CA to let it verify your client certificate. It seems difficult but it's not so. bye Pietro Hi, can you help me ? I have created the certificate using openssl.0.9.5a by the following commands. CA.pl -newreq CA.pl -signreq I have converted in to pkcs12 format by doing the following I have copied the private key from the file newreq.pem in to newcert.pem cacert.pem is in ./demoCA After that I have given the command CA.pl -pkcs12 "My Certificate" I have got the newcert.p12 I couldn't import my certificate (newcert.p12) in Netscape 4.7 I have got the following message after entering the passphrase Unable to import certificates.The file specified is either corrupt or is not a valid file. Regards Vimalan.G __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Importing Certificate Problem.
Thanks It's working fine "[EMAIL PROTECTED]" wrote: I don't know what CA.pl -pkcs12 does nor what it does expect. Anyway, if you simply need to create a PKCS12 file to import in netscape you need at least the file containing the private key (say for example newkey.pem) and the one with your certificate (say newcert.pem). If you also have your CA certificate file in, say, cacert.pem you can put in one PKCS12 file altogether by doing: $openssl pkcs12 -export -out mycerts.p12 -in newcert.pem -inkey newkey.pem -certfile cacert.pem you will be asked for the private key encryption passphrase first, and then for a new passphrase to protect the PKCS12 package. It will create the file mycerts.p12 containing all the things you need. Switch to netscape and import everything selecting mycerts.p12. You will be asked the passphrase protecting the package and the one protecting netscape's key repository, I don't remember in whitch order at the moment, pay attention to message boxes title. Netscape will import your certificate and private key and, more, your CA certificate. Remember to grant rights to your CA to let it verify your client certificate. It seems difficult but it's not so. bye Pietro Hi, can you help me ? I have created the certificate using openssl.0.9.5a by the following commands. CA.pl -newreq CA.pl -signreq I have converted in to pkcs12 format by doing the following I have copied the private key from the file newreq.pem in to newcert.pem cacert.pem is in ./demoCA After that I have given the command CA.pl -pkcs12 "My Certificate" I have got the newcert.p12 I couldn't import my certificate (newcert.p12) in Netscape 4.7 I have got the following message after entering the passphrase Unable to import certificates.The file specified is either corrupt or is not a valid file. Regards Vimalan.G __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] begin:vcard n:Govindaraj;Vimalan tel;work:91-80-286-3394 - 96 Extn.1718 x-mozilla-html:FALSE org:Hewlett - Packard ISO version:2.1 email;internet:[EMAIL PROTECTED] title:Project Trainee adr;quoted-printable:;;Hewlett-Packard,=0D=0A Indian Express Building,=0D=0ADr.B.R.Ambedkar Road,=0D=0A;Bangalore;Karnataka;560 001;India fn:VIMALAN.G end:vcard S/MIME Cryptographic Signature
using user certificate problem
Hi, I'm configuring a apache mod_ssl web server. I've a user.p12 file imported into the netscape browser. (I've made the user.p12 with openssl pkcs12 -export -in user.crt -name "My user certificate" -out user.p12 -clcerts -info -des3 -inkey user.key). When i try to connect to the server i get error message on the netscape: A network error ocurred while ntscape was receiving data. (Network Error: broken pipe). At the some time i got this on the error_log file: [error] mod_ssl: Certificate Verification: Error (20):unable to get local issuer certificate [error] mod_ssl: SSL handshake failed (server www.laplace.inesc.pt:443, client 146.193.24.118) (OpenSSL library error follows) [error] OpenSSL: error: 14089B2:SSL routines:SSL_GET_CLIENT_CERTIFICATE: no certificate returned Any help? Thanks in advance. Osvaldo Brito ---\ [EMAIL PROTECTED] ---/ [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
making a server certificate problem
Hi, I want to generate a server certificate. For that have to sign my server.csr file with my self signed CA. I used this: openssl ca -config openssl.cnf -md md5 -keyfile ca.key -cert ca.crt -in server.csr -out mycert.crt and i've got this error message: wrong number of fields on line 1 (looking for field 6, got 1, '' left) What's the problem? Thanks in advance. Osvaldo Brito [EMAIL PROTECTED] [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Client certificate-problem
Hi, I have created a client certificate with my CA using openssl as openssl ca -in client.csr Then converted it into DER encoded format and trying to import it into browser. But it is not listing the certificate in any catagory of certificates. Even it is not listing it in certificates list when I tried to connect to Apache SSL server with client authentication option enabled. How to solve this? Is it the correct procedure of creating client certificates? I just uncommented the SSLVerifyClient require line in httpd.conf file. In which section I have to specify if I want different access permissions for a particular directory or URL? (I am working on WindowsNT 4.0). Thanks and Regards, Hari. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
trusted certificate problem
Hi, I'm making a PKCS12 certificate with open-ssl and import it in my netscape as. But when I try to send a signed mail with my certificate, I encounter a problem message such as: The certificate issuer for this server has been marked as not trusted by the user. NetScape refuses to connect to this server. I don't know what's means and how to resolve this problem. Thanks, Stone Yang __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: certificate problem :-( please help
I just had the same problem today. I fixed it but I dont know exactly what I did that made it work. I checked the hostname -f and it gave me an alias at first, try hostname -vf and lookfor h_name=`...'. Even if your using a vhost you should use your regular host name in the csr. Good Luck! Barry Hill wrote: Dear open-ssl experts! I´ve turned to the mailing list as I have a problem getting openssl to work. Basically, I can´t get the server's certificate signature to work. Apache fires up OK in non-ssl mode, but the following errors occur in ssl mode: Netscape (Linux): "The server´s certificate has an invalid signature. You will not be able to connect to this site securely". Opera Browser: "Transmission failure" I've enclosed the logs in the hope that someone will be able to help! Please, it´s important! SSL_Engine_Log: [info] Server: Apache/1.3.6, Interface: mod_ssl/2.3.5, Library: OpenSSL/0.9.3a [info] Init: 1st startup round (still not detached) [info] Init: Initializing OpenSSL library [info] Init: Loading certificate private key of SSL-aware server box.company.de:443 [info] Init: 2nd startup round (already detached) [info] Init: Reinitializing OpenSSL library [info] Session Cache Status: 0 elements [info] Init: Seeding PRNG with 8 bytes of entropy [info] Init: Generating temporary RSA private keys (512/1024 bits) [info] Init: Configuring temporary DH parameters (512/1024 bits) [info] Init: Initializing (virtual) servers for SSL [info] Init: Configuring server box.company.de:443 for SSL protocol [info] Connection to child 0 established (server box.company.de:443) [error] SSL handshake failed (client 195.8.91.231, server box.company.de:443) (OpenSSL library error foll [error] OpenSSL: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate [Hint: Subject CN in certificate not server name!?] Apache error_log: [Mon Jul 19 11:51:58 1999] [error] mod_ssl: SSL handshake failed (client 212.41... [Mon Jul 19 11:51:58 1999] [error] OpenSSL: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate [Hint: Subject CN in certificate not server name!?] BTW: the server name I entered when making the certificate is the output of "hostname -f". I just can't see what's wrong... Barry __ 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]
Client Certificate Problem
Running Linux 2.0.36 Apache 1.3.6 Openssl 0.9.3 Mod_ssl 2.3.0 My server is up and running and seems to work fine in secure mode without a clientcert. But every time I create and install a client cert. in netscape 4.06 I getrecieved bad data from server messagethe server log has the following.[Thu May 27 08:33:25 1999] [error] mod_ssl: SSL handshake failed (client 100.100.100.6, server 100.100.100.11:443) (OpenSSL library error follows)[Thu May 27 08:33:25 1999] [error] OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure From reading the openssl.cnf file it says that nsCertType can beleft alone except for object signing. If I am creating a self sign cert.to sign my server.crt. Should I change the openssl.cnf file to allowsigning ca.crt and then change it back before I create my server.crt And do I do the same thing while creating client cert's with CA.shAlso, if anyone has another idea I'd like to hear it.Chris Jensen[EMAIL PROTECTED]
