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]
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
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 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]
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 :)
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
> 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" 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" 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" 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 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" wrote: > > On Mon, Jul 7, 2014 at 9:59 PM, Barbe, Charles > 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" 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" wrote: >> >> On Mon, Jul 7, 2014 at 9:59 PM, Barbe, Charles >> 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
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)
Hi Erik, thanks for replying. I received your mail but not via the list - it hasn't appeared there (yet) ... Problem solved: As usual it was annoyingly simple (and embarassing). I was assuming that when I did a "make certificate" the certificate in "/www/conf" would be altered, but it wasn't. After your mail I intensified my efforts and after copying /usr/src/apache/conf/... to /www/conf it worked! Barry - On Mon, 19 Jul 1999 14:54:07 -0700 (PDT), Erik Kline wrote: >in case you're not on the list. you should verify that the virtual name is >the same as the CN of the cert. __ 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]
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
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
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
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
Re: Certificate problem - SOLVED
On Tue, Jul 8, 2014 at 4:48 PM, Barbe, Charles
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
> 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
> > 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
> > 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 - SOLVED
On Tue, Jul 8, 2014 at 7:00 PM, Dave Thompson 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 - 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 > 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
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]
RE: Certificate Problem / get_peer_certificate + ssldump
eCipherSpec 1 11 2.2448 (0.) S>CV3.1(36) Handshake 1 12 2.2465 (0.0017) C>SV3.1(103) application_data 1 13 2.2474 (0.0008) S>CV3.1(40) application_data 1 14 2.2485 (0.0010) C>SV3.1(159) application_data 1 15 2.2500 (0.0014) S>CV3.1(52) application_data 1 16 2.2508 (0.0008) S>CV3.1(5200) application_data download: 1 26 73.8719 (0.0414) C>SV3.1(115) Handshake 1 27 73.8729 (0.0009) S>CV3.1(94) Handshake 1 28 73.9787 (0.1058) S>CV3.1(1864) Handshake 1 29 73.9789 (0.0002) S>CV3.1(336) Handshake 1 30 73.9789 (0.) S>CV3.1(35) Handshake 1 31 74.0222 (0.0433) C>SV3.1(954) Handshake 1 32 74.0234 (0.0011) S>CV3.1(22) Alert 174.0244 (0.0009) S>C TCP FIN 1 33 74.0255 (0.0011) C>SV3.1(154) Handshake 1 34 74.0255 (0.) C>SV3.1(73) Handshake 1 35 74.0255 (0.) C>SV3.1(21) ChangeCipherSpec 1 36 74.0255 (0.) C>SV3.1(36) Handshake 174.0256 (0.0001) C>S 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]
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]
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? key size problem? help!!!
On Fri, Jan 18, 2002 at 12:08:36PM -0500, Mark Lidd wrote: > A transcript is the following: > > bash-2.05$ openssl s_client -connect autonet.va.autometric.com:443 -ssl2 ... > Ciphers common between both SSL endpoints: > RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5 > EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5 ... > New, SSLv2, Cipher is DES-CBC3-MD5 ... > Insufficient encryptionInsufficient encryption > This document requires a larger secret key size for encryption than your > browser is capable of supporting. > Forbidden > Forbidden > The proxy's access control configuration denies access to > the requested object through this proxy. > closed Obviously the "Insufficient encryption" argument is badly implemented. DES-CBC3-MD5 should be strong enough. If you would have used netscape, it would choose RC4-MD5 and it seems that this is hardcoded into the server. Specify RC4-MD5 as cipher: openssl s_client -connect autonet.va.autometric.com:443 -ssl2 -cipher RC4-MD5 Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
