Re: openssl rsa command
On Wed, Dec 05, 2012 at 10:38:59AM -0800, Alex Chen wrote: > I am trying to change the password of a private key with 'openssl rsa' > command. The original key file, server.key.enc has the following format: > -BEGIN ENCRYPTED PRIVATE KEY- > > -END ENCRYPTED PRIVATE KEY- This is a private key in PKCS#8 format. > > When I used the command "openssl rsa -in server.key.enc -passin > pass:old_password -out server.key", a new decrypted key file is > generated with the following format: > -BEGIN RSA PRIVATE KEY- > ... > -END RSA PRIVATE KEY- > > But when I use the command "openssl rsa -in server.key.enc -passin > pass:old_password -out server.key -passout pass:new_password", hoping > the new key file will be encrypted with the new password, I still get > the same decrypted key file below > -BEGIN RSA PRIVATE KEY- > ... > -END RSA PRIVATE KEY- You must use one of the -des, -aes128, -aes192, -aes256 options to get an encrypted RSA key. It then looks like: -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,B9A804CC6B6B2B3B fpz9643saAI47PWga4Or3xcBY372owuck/9jGO19rBbrfW6NSyUvJevHRWvcHNGM . -END RSA PRIVATE KEY- However, this format is an OpenSSL specific extension. To get the key in the same format (PKCS#8) as before, just with a changed password, use: openssl pkcs8 -topk8 -in server.key.enc -passin pass:old_password \ -out server.key -passout pass:new_password" Cheers Christian __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to over-ride SSL_CTX_use_PrivateKey_file() behavior with custom engine
Thanks Steve and Kent for the pointers. Makes things clear for now. On Thu, Dec 6, 2012 at 4:22 AM, Dr. Stephen Henson wrote: > On Wed, Dec 05, 2012, Ashok C wrote: > > > Hi, > > > > Our current SSL server loads plain-text private keys using the > > SSL_CTX_use_PrivateKey_file() > > method. We are moving from this strategy to use custom encrypted private > > keys using the TPM concept. For this, we have an engine implemented. Now > > the question is this. > > > > Does my SSL server need to change from loading private keys using > > SSL_CTX_use_PrivateKey_file() > > method to use this method --> ENGINE_load_private_key(ENGINE *e, const > char > > *key_id, > > > > UI_METHOD *ui_method, void *callback_data) > > > > > > You can't use SSL_CTX_use_PrivateKey_file to load an ENGINE specific key. > Instead you use ENGINE_load_private_key() to load the key into an EVP_PKEY > structure and then pass that to SSL_CTX_use_PrivateKey(). > > 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: How to over-ride SSL_CTX_use_PrivateKey_file() behavior with custom engine
On Wed, Dec 05, 2012, Ashok C wrote: > Hi, > > Our current SSL server loads plain-text private keys using the > SSL_CTX_use_PrivateKey_file() > method. We are moving from this strategy to use custom encrypted private > keys using the TPM concept. For this, we have an engine implemented. Now > the question is this. > > Does my SSL server need to change from loading private keys using > SSL_CTX_use_PrivateKey_file() > method to use this method --> ENGINE_load_private_key(ENGINE *e, const char > *key_id, > > UI_METHOD *ui_method, void *callback_data) > > You can't use SSL_CTX_use_PrivateKey_file to load an ENGINE specific key. Instead you use ENGINE_load_private_key() to load the key into an EVP_PKEY structure and then pass that to SSL_CTX_use_PrivateKey(). 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
Head check on SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option
The SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option only affects how the OUTBOUND (i.e. SSL_write) records are split (or not), correct? It doesn't define any behavior for how the INBOUND records (i.e. SSL_read) should be split (or not), correct? So, it's possible that different sides of an SSL connection could be splitting (or not) the records different ways. For example, suppose the client does NOT have the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option set, but the server does. In this scenario the records coming from the client going to the server would be split and contain empty fragments, but the records coming from the server going to the client would NOT contain empty fragments. Is that correct? Thank you.
Re: How to over-ride SSL_CTX_use_PrivateKey_file() behavior with custom engine
Hi Ashok, On Wed, Dec 5, 2012 at 12:29 AM, Ashok C wrote: > Hi, > > Our current SSL server loads plain-text private keys using the > SSL_CTX_use_PrivateKey_file() method. We are moving from this strategy to > use custom encrypted private keys using the TPM concept. For this, we have > an engine implemented. Now the question is this. > > Does my SSL server need to change from loading private keys using > SSL_CTX_use_PrivateKey_file() method to use this method --> > ENGINE_load_private_key(ENGINE *e, const char *key_id, > > UI_METHOD *ui_method, void *callback_data) > > > Or can this be achieved by using the SSL_CTX_use_PrivateKey_file() method > itself and the openssl takes care of loading my encrypted private key with > the help of my implemented engine. Basically wanted to understand if the > SSL_CTX method for loading private keys has the support for loading engine > specific keys. Last I knew there were two ways to get your TPM key loaded through an engine. Directly in your app, using code like: ENGINE_by_id(); ENGINE_init(); ENGINE_set_default_RSA(); ENGINE_load_private_key(); ... (use key ... and indirectly by using an openssl-config enabled app, and the RSA_* APIs to load the key. Basically in this case you have a system openssl config that you've added something like: --[cut]-- openssl_conf = openssl_def [openssl_def] engines = engine_section [engine_section] foo = tpm_section [tpm_section] dynamic_path = /usr/local/ssl/lib/engines/libtpm.so engine_id = tpm default_algorithms = RAND,RSA init = 1 --[cut]-- then your app needs to be compiled with -DOPENSSL_LOAD_CONF=1, which triggers hooks in RSA_* apis which will read the config file and redirect key loading to your engine. Kent > > -- > > Ashok > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl rsa command
I am trying to change the password of a private key with 'openssl rsa' command. The original key file, server.key.enc has the following format: -BEGIN ENCRYPTED PRIVATE KEY- -END ENCRYPTED PRIVATE KEY- When I used the command "openssl rsa -in server.key.enc -passin pass:old_password -out server.key", a new decrypted key file is generated with the following format: -BEGIN RSA PRIVATE KEY- ... -END RSA PRIVATE KEY- But when I use the command "openssl rsa -in server.key.enc -passin pass:old_password -out server.key -passout pass:new_password", hoping the new key file will be encrypted with the new password, I still get the same decrypted key file below -BEGIN RSA PRIVATE KEY- ... -END RSA PRIVATE KEY- Do I use the command correctly, or do I misunderstand what the argument meant? What is the correct way to re-encrypt a RSA private key with a new password? Thanks for any help. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Openssl not properly validating certificates?
On Wed, Dec 5, 2012 at 12:18 PM, Jakob Bohm wrote: > On 12/5/2012 5:30 PM, Will Nordmeyer wrote: >> >> On Wed, Dec 5, 2012 at 11:22 AM, Dr. Stephen Henson >> wrote: >>> >>> On Wed, Dec 05, 2012, Will Nordmeyer wrote: >>> On Wed, Dec 5, 2012 at 10:47 AM, Dr. Stephen Henson wrote: > > On Wed, Dec 05, 2012, Will Nordmeyer wrote: > >> They are US. gov't certificates & CRLs, so providing them is a little >> complicated. Before I had the proper root & intermediate CAs loaded >> and hashed, I would get errors about missing certs in the chain. >> Similarly, before I loaded the CRL, it would have issues. >> >> The CERTs are in PEM formats, as well as the CRLs. >> > > I'd suggest you try a version of OpenSSL from the website to see if you > have > problems with that. > > Version "1.0.0-25" or "1.0.0-fips" is not a standard OpenSSL version. > I installed 1.0.1c (and verified it is the one being called). When I first reran the commands as I listed earlier, I got error 20 at 0 depth lookup:unable to get local issuer certificate I added -CApath /etc/ssl/certs and everything comes back OK again. >>> >>> >>> >>> Try a sanity check on a certificate, for example: >>> >>> openssl x509 -in TestForty_Expired.pem -noout -dates >>> >> OK... now I have insanity - >> >> openssl x509 -in TestFortyTwo_Expired.pem -noout -dates >> notBefore=Dec 30 18:09:39 2008 GMT >> notAfter=Dec 29 18:09:39 2014 GMT >> >> I have certificate 42 imported into my Internet Explorer browser, it >> indicates the validity dates as: >> IE tells me it is valid from 9/13/2011 to 9/14/2011 >> > Ok, try > > openssl x509 -n TestFortyTwo_Expired.pem -noout -text > > and compare all the details to what you see in IE. > > Maybe it is not the same certificate. > > >> Can I switch careers to basket weaving? > > > Nah, I think that got outsourced (back) to China too. > > > Enjoy > AH - found the issue... my TestFortyTwo_Expired.pem has 3 certs in it - the root cert, the intermediate cert and then the user cert. I stripped out the root & intermediate cert from the PEM file and openssl now properly reports TestFortyTwo_Expired.pem as expired. I did the same clean up on TestThirtySeven_Revoked.pem - took out the root cert & the intermediate cert and then ran it through dates - dates are fine ... ran it through verify with the following command to see a revoked certificate response: # openssl verify -CApath /etc/ssl/certs -crl_check_all -verbose -purpose sslclient TestThirtySeven_Revoked.pem TestThirtySeven_Revoked.pem: OK __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Openssl not properly validating certificates?
On 12/5/2012 5:30 PM, Will Nordmeyer wrote: On Wed, Dec 5, 2012 at 11:22 AM, Dr. Stephen Henson wrote: On Wed, Dec 05, 2012, Will Nordmeyer wrote: On Wed, Dec 5, 2012 at 10:47 AM, Dr. Stephen Henson wrote: On Wed, Dec 05, 2012, Will Nordmeyer wrote: They are US. gov't certificates & CRLs, so providing them is a little complicated. Before I had the proper root & intermediate CAs loaded and hashed, I would get errors about missing certs in the chain. Similarly, before I loaded the CRL, it would have issues. The CERTs are in PEM formats, as well as the CRLs. I'd suggest you try a version of OpenSSL from the website to see if you have problems with that. Version "1.0.0-25" or "1.0.0-fips" is not a standard OpenSSL version. I installed 1.0.1c (and verified it is the one being called). When I first reran the commands as I listed earlier, I got error 20 at 0 depth lookup:unable to get local issuer certificate I added -CApath /etc/ssl/certs and everything comes back OK again. Try a sanity check on a certificate, for example: openssl x509 -in TestForty_Expired.pem -noout -dates OK... now I have insanity - openssl x509 -in TestFortyTwo_Expired.pem -noout -dates notBefore=Dec 30 18:09:39 2008 GMT notAfter=Dec 29 18:09:39 2014 GMT I have certificate 42 imported into my Internet Explorer browser, it indicates the validity dates as: IE tells me it is valid from 9/13/2011 to 9/14/2011 Ok, try openssl x509 -n TestFortyTwo_Expired.pem -noout -text and compare all the details to what you see in IE. Maybe it is not the same certificate. Can I switch careers to basket weaving? Nah, I think that got outsourced (back) to China too. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Openssl not properly validating certificates?
On Wed, Dec 5, 2012 at 11:22 AM, Dr. Stephen Henson wrote: > On Wed, Dec 05, 2012, Will Nordmeyer wrote: > >> On Wed, Dec 5, 2012 at 10:47 AM, Dr. Stephen Henson >> wrote: >> > On Wed, Dec 05, 2012, Will Nordmeyer wrote: >> > >> >> They are US. gov't certificates & CRLs, so providing them is a little >> >> complicated. Before I had the proper root & intermediate CAs loaded >> >> and hashed, I would get errors about missing certs in the chain. >> >> Similarly, before I loaded the CRL, it would have issues. >> >> >> >> The CERTs are in PEM formats, as well as the CRLs. >> >> >> > >> > I'd suggest you try a version of OpenSSL from the website to see if you >> > have >> > problems with that. >> > >> > Version "1.0.0-25" or "1.0.0-fips" is not a standard OpenSSL version. >> > >> I installed 1.0.1c (and verified it is the one being called). >> >> When I first reran the commands as I listed earlier, I got >> error 20 at 0 depth lookup:unable to get local issuer certificate >> >> I added -CApath /etc/ssl/certs and everything comes back OK again. > > > Try a sanity check on a certificate, for example: > > openssl x509 -in TestForty_Expired.pem -noout -dates > OK... now I have insanity - openssl x509 -in TestFortyTwo_Expired.pem -noout -dates notBefore=Dec 30 18:09:39 2008 GMT notAfter=Dec 29 18:09:39 2014 GMT I have certificate 42 imported into my Internet Explorer browser, it indicates the validity dates as: IE tells me it is valid from 9/13/2011 to 9/14/2011 Can I switch careers to basket weaving? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Openssl not properly validating certificates?
On Wed, Dec 05, 2012, Will Nordmeyer wrote: > On Wed, Dec 5, 2012 at 10:47 AM, Dr. Stephen Henson wrote: > > On Wed, Dec 05, 2012, Will Nordmeyer wrote: > > > >> They are US. gov't certificates & CRLs, so providing them is a little > >> complicated. Before I had the proper root & intermediate CAs loaded > >> and hashed, I would get errors about missing certs in the chain. > >> Similarly, before I loaded the CRL, it would have issues. > >> > >> The CERTs are in PEM formats, as well as the CRLs. > >> > > > > I'd suggest you try a version of OpenSSL from the website to see if you have > > problems with that. > > > > Version "1.0.0-25" or "1.0.0-fips" is not a standard OpenSSL version. > > > I installed 1.0.1c (and verified it is the one being called). > > When I first reran the commands as I listed earlier, I got > error 20 at 0 depth lookup:unable to get local issuer certificate > > I added -CApath /etc/ssl/certs and everything comes back OK again. Try a sanity check on a certificate, for example: openssl x509 -in TestForty_Expired.pem -noout -dates 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: [openssl-users] Openssl not properly validating certificates?
On Wed, Dec 5, 2012 at 10:47 AM, Dr. Stephen Henson wrote: > On Wed, Dec 05, 2012, Will Nordmeyer wrote: > >> They are US. gov't certificates & CRLs, so providing them is a little >> complicated. Before I had the proper root & intermediate CAs loaded >> and hashed, I would get errors about missing certs in the chain. >> Similarly, before I loaded the CRL, it would have issues. >> >> The CERTs are in PEM formats, as well as the CRLs. >> > > I'd suggest you try a version of OpenSSL from the website to see if you have > problems with that. > > Version "1.0.0-25" or "1.0.0-fips" is not a standard OpenSSL version. > I installed 1.0.1c (and verified it is the one being called). When I first reran the commands as I listed earlier, I got error 20 at 0 depth lookup:unable to get local issuer certificate I added -CApath /etc/ssl/certs and everything comes back OK again. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Openssl not properly validating certificates?
On Wed, Dec 05, 2012, Will Nordmeyer wrote: > They are US. gov't certificates & CRLs, so providing them is a little > complicated. Before I had the proper root & intermediate CAs loaded > and hashed, I would get errors about missing certs in the chain. > Similarly, before I loaded the CRL, it would have issues. > > The CERTs are in PEM formats, as well as the CRLs. > I'd suggest you try a version of OpenSSL from the website to see if you have problems with that. Version "1.0.0-25" or "1.0.0-fips" is not a standard OpenSSL version. 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: [openssl-users] Openssl not properly validating certificates?
They are US. gov't certificates & CRLs, so providing them is a little complicated. Before I had the proper root & intermediate CAs loaded and hashed, I would get errors about missing certs in the chain. Similarly, before I loaded the CRL, it would have issues. The CERTs are in PEM formats, as well as the CRLs. On Wed, Dec 5, 2012 at 10:23 AM, Erwann Abalea wrote: > OpenSSL 1.0.1 works fine here, both with expired and revoked certificates > (i.e. correctly reports the status). > Could you share your elements (certs, CRLs)? > > -- > Erwann ABALEA > - > chlorophytophonie: musique pour les plantes vertes > > Le 05/12/2012 15:11, Will Nordmeyer a écrit : > >> Hi, I've done some googling and failed to come up with an answer... >> >> I have openssl 1.0.0-25 (also seeing it as 1.0.0-fips) installed on >> a test server running CentOS 6.3 (2.6.32-279.14.1.el6.x86_64). It is >> the latest one avaialble from the CentOS repositories. >> >> I've downloaded and set up several Certificate Authorities as trusted >> certs and their accompanying CRLs. I've created the hash links for >> the CRLs and CAs as well. >> >> When I run a test on some test certificates I received, they all come >> back OK, even though some are expired and some are revoked. >> >> I've run the following verify command and expected different results >> to flag TestOne as valid, TestThirtySeven as Revoked and TestForty as >> expired. >> >> I also tried crl_check_all and purpose flags, with no different results. >> >> [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose >> TestOne_Valid.pem >> TestOne_Valid.pem: OK >> [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose >> TestForty_Expired.pem >> TestForty_Expired.pem: OK >> [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose >> TestThirtySeven_Revoked.pem >> TestThirtySeven_Revoked.pem: OK >> [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose >> -purpose sslclient TestOne_Valid.pem >> TestOne_Valid.pem: OK >> [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose >> -purpose sslclient TestForty_Expired.pem >> TestForty_Expired.pem: OK >> [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose >> -purpose sslclient TestThirtySeven_Revoked.pem >> TestThirtySeven_Revoked.pem: OK >> [root@dmapsdev01 TestCerts]# >> >> Similarly, when I run from a browser, with tomcat configured for CRL >> checking (using APR & tcnative), tomcat lets the expired and revoked >> certificates pass. > > > __ > 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: [openssl-users] Openssl not properly validating certificates?
OpenSSL 1.0.1 works fine here, both with expired and revoked certificates (i.e. correctly reports the status). Could you share your elements (certs, CRLs)? -- Erwann ABALEA - chlorophytophonie: musique pour les plantes vertes Le 05/12/2012 15:11, Will Nordmeyer a écrit : Hi, I've done some googling and failed to come up with an answer... I have openssl 1.0.0-25 (also seeing it as 1.0.0-fips) installed on a test server running CentOS 6.3 (2.6.32-279.14.1.el6.x86_64). It is the latest one avaialble from the CentOS repositories. I've downloaded and set up several Certificate Authorities as trusted certs and their accompanying CRLs. I've created the hash links for the CRLs and CAs as well. When I run a test on some test certificates I received, they all come back OK, even though some are expired and some are revoked. I've run the following verify command and expected different results to flag TestOne as valid, TestThirtySeven as Revoked and TestForty as expired. I also tried crl_check_all and purpose flags, with no different results. [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose TestOne_Valid.pem TestOne_Valid.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose TestForty_Expired.pem TestForty_Expired.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose TestThirtySeven_Revoked.pem TestThirtySeven_Revoked.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose -purpose sslclient TestOne_Valid.pem TestOne_Valid.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose -purpose sslclient TestForty_Expired.pem TestForty_Expired.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose -purpose sslclient TestThirtySeven_Revoked.pem TestThirtySeven_Revoked.pem: OK [root@dmapsdev01 TestCerts]# Similarly, when I run from a browser, with tomcat configured for CRL checking (using APR & tcnative), tomcat lets the expired and revoked certificates pass. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Openssl not properly validating certificates?
Hi, I've done some googling and failed to come up with an answer... I have openssl 1.0.0-25 (also seeing it as 1.0.0-fips) installed on a test server running CentOS 6.3 (2.6.32-279.14.1.el6.x86_64). It is the latest one avaialble from the CentOS repositories. I've downloaded and set up several Certificate Authorities as trusted certs and their accompanying CRLs. I've created the hash links for the CRLs and CAs as well. When I run a test on some test certificates I received, they all come back OK, even though some are expired and some are revoked. I've run the following verify command and expected different results to flag TestOne as valid, TestThirtySeven as Revoked and TestForty as expired. I also tried crl_check_all and purpose flags, with no different results. [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose TestOne_Valid.pem TestOne_Valid.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose TestForty_Expired.pem TestForty_Expired.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose TestThirtySeven_Revoked.pem TestThirtySeven_Revoked.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose -purpose sslclient TestOne_Valid.pem TestOne_Valid.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose -purpose sslclient TestForty_Expired.pem TestForty_Expired.pem: OK [root@dmapsdev01 TestCerts]# openssl verify -crl_check_all -verbose -purpose sslclient TestThirtySeven_Revoked.pem TestThirtySeven_Revoked.pem: OK [root@dmapsdev01 TestCerts]# Similarly, when I run from a browser, with tomcat configured for CRL checking (using APR & tcnative), tomcat lets the expired and revoked certificates pass. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
