Re: Using pkcs12
Just because the PKCS12 is going to be YOUR cert (to sign), it requires this password . It can not be optional because when you are about to install this file in an email client, the email client needs to make sure it's yours; so the password is then asked. No password is requested for OTHER's certs, because those are used just to encrypt and for verification of other's signatures. In other words, if I find YOUR pkcs12 file somewhere and I want to install it in my email client, to sign or forge your mails, and if you had made it with the -non possible- optional password OFF, I would be free to forge your signed mails. For the same reason the PKCS12 has to be produced by the person him/her self. You can not tell somebody else: hey, this is my cert AND PRIVATE KEY, please produce my pkcs12. And for reasons like above it is not simple to have a reliable WebService which gives you: key pairs, cert, pkcs12, etc., because then your private and personal data would be FROM THE START in the hands of somebody else, unless the trust and reputation are built by the members, users, etc., , which might break after some critic stage, etc., (another topic) Greetings tushar ganguli wrote: Hi, Shouldn't that be optional. Does it compulsorily encrypt all certificates and keys with the export password? Regards, Tushar. -- View this message in context: http://www.nabble.com/Using-pkcs12-tp25234677p25234983.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Using pkcs12
tushar ganguli wrote: Hi, I have been using the PKCS12 command and it seems that the command compulsorily asks for the password. Shouldn't that be optional. Does it compulsorily encrypt all certificates and keys with the export password? Regards, Tushar. Use the command line option -password pass: and there will be no password. -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. Cell: 613-608-9752 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RSA decryption and pkcs11 engine load in the same line problem
hi all, Does anyone know how do i combine the loading of engine and decryption command all in the same line? i did this and this works OpenSSL engine -t dynamic -pre SO_engine_pkcs11 -pre ID:pkcs11 -pre LIST_ADD:1 -pre Load -pre MODULE_PATH:OCSCryptolib_P11.dll dynamic Dynamic engine loading support [success]: SO_PATH:engine_pkcs11 [success]:ID:pkcs11 [success]:LIST_ADD:1 [success]:LOAD [success]:MODULE_PATH:OCSCryptolib_P11.dll Loaded: pkcs11 pkcs11 engine [available] OpenSSL rsautl -decrypt -in cipher.txt -out raw.txt -engine pkcs11 -keyform engine -inkey 0:k9n878878778ae8898989d -passin file:password.txt engine pkcs11 set. Loading 'screen' into random state - done This works however if i use the below command it returns the following error, OpenSSL engine -t dynamic -pre SO_engine_pkcs11 -pre ID:pkcs11 -pre LIST_ADD:1 -pre Load -pre MODULE_PATH:OCSCryptolib_P11.dll -pre 'rsautl -decrypt -in cipher.txt -out raw.txt -engine pkcs11 -keyform engine -inkey 0:k9n878878778ae8898989d -passin file:password.txt' dynamic Dynamic engine loading support [success]: SO_PATH:engine_pkcs11 [success]:ID:pkcs11 [success]:LIST_ADD:1 [success]:LOAD [success]:MODULE_PATH:OCSCryptolib_P11.dll [Failure]: rsautl -decrypt -in cipher.txt -out raw.txt -engine pkcs11 -keyform engine -inkey 0:k9n878878778ae8898989d -passin file:password.txt 5044:error:260AC089: engine routines:INT_CTRL_HELPER:invalid cmd name:.\crypto\engine\eng_ctrl.c:134: 5044:error:260AB089:engine routines:ENGINE_ctrl_cmd_string:invalid cmd name:.\crypto\engine\eng_ctrl.c:316: Loaded:pkcs11 pkcs11 engine [ available ] Why is this so??? it tearing me out!!! pls help!!! -- View this message in context: http://www.nabble.com/RSA-decryption-and-pkcs11-engine-load-in-the-same-line-problem-tp25235672p25235672.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Verify certificate using subordinate ca
Hi, It there a way to verify certificate with out root ca? I have 4 certificate: rootca.pem is the root ca (self signed). subca.pem was signed by rootca.pem. cert1.pem cert2.pem was signed by subca.pem. I was supposed to configure the client and server using subca.pem as ca, and cert1.pem cert2.pem as certificate. It seem that openssl still try to find rootca.pem to verfiy subca.pem when handshake. But I don't what root.pem can bo accessed for keeping it safe. So It there a way to verify certificate with out root ca, only using sub ca and certificate signed by sub ca? Thanks. Br Ben
Re: Verify certificate using subordinate ca
Hi, Hmm... I've had the same issue. Basically it came down to how do you know if the sub is reliable if you do not know whether to trust the root? If you do not wish to have the root as part of the chain, create a new chain where the sub is the root What is the reason you do not want to use the root in the chain check, but it should be part of the chain? HTH Regards, Serge Fonville On Tue, Sep 1, 2009 at 1:04 PM, Yin, Ben 1. (NSN - CN/Cheng Du)ben.1@nsn.com wrote: Hi, It there a way to verify certificate with out root ca? I have 4 certificate: rootca.pem is the root ca (self signed). subca.pem was signed by rootca.pem. cert1.pem cert2.pem was signed by subca.pem. I was supposed to configure the client and server using subca.pem as ca, and cert1.pem cert2.pem as certificate. It seem that openssl still try to find rootca.pem to verfiy subca.pem when handshake. But I don't what root.pem can bo accessed for keeping it safe. So It there a way to verify certificate with out root ca, only using sub ca and certificate signed by sub ca? Thanks. Br Ben __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Obsolete openssl.cnf
Hi, I was wondering, is it possible to specify all settings that are in openssl.cnf on the commandline as well? This would make generating certificates a lot easier. Thanks in advance Regards, Serge Fonville __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
bug report: bn_rand function
hi, I am using bn_rand function which is taking more than 10 seconds to execute. OS: Windows XP SP3 OS Locale: Swidish I am not able to reproduce issue on other machine. Can you please guide me on what can reason behind BN_Rand taking so long? Any help is appreciated. Thank you Have a nice day! -- Regards, Dipti
RE: Verify certificate using subordinate ca
Hi Serge, My intention is to keep my root ca out of compromise. We want to use sub ca to splite the domain in the our whole network. Then, we can easy to re-sign a new sub ca and publish it if we find one domain sub ca was compromised. And if we expose the the root ca to public ,it hard to maintain if root ca was cracked. And as you said, create a new chain and let sub ca as root, I don't know how to do it. In my testing, I set verify depth to 1. I guess it will make chain only include certificate and sub ca. the testing show that the openssl still try to find the issuer of sub ca, and so the verification was failed. Here is the output: -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 20:unable to get local issuer certificate -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 27:certificate not trusted -with certificate at depth: 0 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA subject = /C=FI/ST=Tampere/L=Tampere/O=NSN/CN=lab. err 27:certificate not trusted And FYI. Here is the complete chain verfication output. -with certificate at depth: 2 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA err 0:ok -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 0:ok -with certificate at depth: 0 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA subject = /C=FI/ST=Tampere/L=Tampere/O=NSN/CN=lab. err 0:ok Thanks. Br Ben -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville Sent: Tuesday, September 01, 2009 2:14 PM To: openssl-users@openssl.org Subject: Re: Verify certificate using subordinate ca Hi, Hmm... I've had the same issue. Basically it came down to how do you know if the sub is reliable if you do not know whether to trust the root? If you do not wish to have the root as part of the chain, create a new chain where the sub is the root What is the reason you do not want to use the root in the chain check, but it should be part of the chain? HTH Regards, Serge Fonville On Tue, Sep 1, 2009 at 1:04 PM, Yin, Ben 1. (NSN - CN/Cheng Du)ben.1@nsn.com wrote: Hi, It there a way to verify certificate with out root ca? I have 4 certificate: rootca.pem is the root ca (self signed). subca.pem was signed by rootca.pem. cert1.pem cert2.pem was signed by subca.pem. I was supposed to configure the client and server using subca.pem as ca, and cert1.pem cert2.pem as certificate. It seem that openssl still try to find rootca.pem to verfiy subca.pem when handshake. But I don't what root.pem can bo accessed for keeping it safe. So It there a way to verify certificate with out root ca, only using sub ca and certificate signed by sub ca? Thanks. Br Ben __ 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: Verify certificate using subordinate ca
I only want to verfiy the signature (I mean the procedure when sub ca sign the certiticate). So I guess sub ca and certification should has enough info to do it because we needn't root ca when we use sub ca to sign the certificate. Is there a way for this requirement? Thanks. Br Ben -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Yin, Ben 1. (NSN - CN/Cheng Du) Sent: Tuesday, September 01, 2009 3:06 PM To: openssl-users@openssl.org Subject: RE: Verify certificate using subordinate ca Hi Serge, My intention is to keep my root ca out of compromise. We want to use sub ca to splite the domain in the our whole network. Then, we can easy to re-sign a new sub ca and publish it if we find one domain sub ca was compromised. And if we expose the the root ca to public ,it hard to maintain if root ca was cracked. And as you said, create a new chain and let sub ca as root, I don't know how to do it. In my testing, I set verify depth to 1. I guess it will make chain only include certificate and sub ca. the testing show that the openssl still try to find the issuer of sub ca, and so the verification was failed. Here is the output: -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 20:unable to get local issuer certificate -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 27:certificate not trusted -with certificate at depth: 0 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA subject = /C=FI/ST=Tampere/L=Tampere/O=NSN/CN=lab. err 27:certificate not trusted And FYI. Here is the complete chain verfication output. -with certificate at depth: 2 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA err 0:ok -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 0:ok -with certificate at depth: 0 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA subject = /C=FI/ST=Tampere/L=Tampere/O=NSN/CN=lab. err 0:ok Thanks. Br Ben -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville Sent: Tuesday, September 01, 2009 2:14 PM To: openssl-users@openssl.org Subject: Re: Verify certificate using subordinate ca Hi, Hmm... I've had the same issue. Basically it came down to how do you know if the sub is reliable if you do not know whether to trust the root? If you do not wish to have the root as part of the chain, create a new chain where the sub is the root What is the reason you do not want to use the root in the chain check, but it should be part of the chain? HTH Regards, Serge Fonville On Tue, Sep 1, 2009 at 1:04 PM, Yin, Ben 1. (NSN - CN/Cheng Du)ben.1@nsn.com wrote: Hi, It there a way to verify certificate with out root ca? I have 4 certificate: rootca.pem is the root ca (self signed). subca.pem was signed by rootca.pem. cert1.pem cert2.pem was signed by subca.pem. I was supposed to configure the client and server using subca.pem as ca, and cert1.pem cert2.pem as certificate. It seem that openssl still try to find rootca.pem to verfiy subca.pem when handshake. But I don't what root.pem can bo accessed for keeping it safe. So It there a way to verify certificate with out root ca, only using sub ca and certificate signed by sub ca? Thanks. Br Ben __ 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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify certificate using subordinate ca
Based on what you state. There is no purpose for the root CA. What do you mean by compromised. If you publish a CA certificate to clients, it does not include the key. (normally) So the only thing a client can do is use it in the session at best. There is NO way a client can use a CA certificate to sign anything without the corresponding key. I have a chain on my website, and noone (except me, because I can access the server) is able to sign anything. Since the CAs are only used for signing and verifying and not for encrypting, if the CA keys are stored safely, there is no 'compromise' Are you distributing the keys as well? HTH Regards, Serge Fonville On Tue, Sep 1, 2009 at 2:13 PM, Yin, Ben 1. (NSN - CN/Cheng Du)ben.1@nsn.com wrote: I only want to verfiy the signature (I mean the procedure when sub ca sign the certiticate). So I guess sub ca and certification should has enough info to do it because we needn't root ca when we use sub ca to sign the certificate. Is there a way for this requirement? Thanks. Br Ben -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Yin, Ben 1. (NSN - CN/Cheng Du) Sent: Tuesday, September 01, 2009 3:06 PM To: openssl-users@openssl.org Subject: RE: Verify certificate using subordinate ca Hi Serge, My intention is to keep my root ca out of compromise. We want to use sub ca to splite the domain in the our whole network. Then, we can easy to re-sign a new sub ca and publish it if we find one domain sub ca was compromised. And if we expose the the root ca to public ,it hard to maintain if root ca was cracked. And as you said, create a new chain and let sub ca as root, I don't know how to do it. In my testing, I set verify depth to 1. I guess it will make chain only include certificate and sub ca. the testing show that the openssl still try to find the issuer of sub ca, and so the verification was failed. Here is the output: -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 20:unable to get local issuer certificate -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 27:certificate not trusted -with certificate at depth: 0 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA subject = /C=FI/ST=Tampere/L=Tampere/O=NSN/CN=lab. err 27:certificate not trusted And FYI. Here is the complete chain verfication output. -with certificate at depth: 2 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA err 0:ok -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 0:ok -with certificate at depth: 0 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA subject = /C=FI/ST=Tampere/L=Tampere/O=NSN/CN=lab. err 0:ok Thanks. Br Ben -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville Sent: Tuesday, September 01, 2009 2:14 PM To: openssl-users@openssl.org Subject: Re: Verify certificate using subordinate ca Hi, Hmm... I've had the same issue. Basically it came down to how do you know if the sub is reliable if you do not know whether to trust the root? If you do not wish to have the root as part of the chain, create a new chain where the sub is the root What is the reason you do not want to use the root in the chain check, but it should be part of the chain? HTH Regards, Serge Fonville On Tue, Sep 1, 2009 at 1:04 PM, Yin, Ben 1. (NSN - CN/Cheng Du)ben.1@nsn.com wrote: Hi, It there a way to verify certificate with out root ca? I have 4 certificate: rootca.pem is the root ca (self signed). subca.pem was signed by rootca.pem. cert1.pem cert2.pem was signed by subca.pem. I was supposed to configure the client and server using subca.pem as ca, and cert1.pem cert2.pem as certificate. It seem that openssl still try to find rootca.pem to verfiy subca.pem when handshake. But I don't what root.pem can bo accessed for keeping it safe. So It there a way to verify certificate with out root ca, only using sub ca and certificate signed by sub ca? Thanks. Br Ben __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@openssl.org Automated List Manager majord...@openssl.org
Verify certificate using subordinate ca
Hi, It there a way to verify certificate with out root ca? I have 4 certificate: rootca.pem is the root ca (self signed). subca.pem was signed by rootca.pem. cert1.pem cert2.pem was signed by subca.pem. I was supposed to configure the client and server using subca.pem as ca, and cert1.pem cert2.pem as certificate. It seem that openssl still try to find rootca.pem to verfiy subca.pem when handshake. But I don't what root.pem can bo accessed for keeping it safe. So It there a way to verify certificate with out root ca, only using sub ca and certificate signed by sub ca? Thanks. Br Ben
Need help with s_client
Hi All, I want to write a SSL client which will not ack for all the data on TCP layer and then close a connection i.e I want to test the tcp close when there is unacknowledged data on socket. I tried using s_client and tried to modify the code where there is: k=SSL_read(con,sbuf,1024 /* BUFSIZZ */ ); I tried changing the buffer size and tried adding delay after first read, but looking at tcp conn on ethereal I saw that even if my client is not reading the data , the data is getting acked back. I will really appreciate any ideas or tools to achieve this. Ritesh
RE: Verify certificate using subordinate ca
No. In our enviroment. The root CA private key is isolated and absolutly safe. Regarding the compromised, I means CA can't be trusted any more, Such as the private key was stolen some how or someone find a way to figure out private key for one CA. it easy to set up new sub ca in one domain if those compromise happened on sub ca. but if it happened on root ca, it's quite hard to fix the our whole network. Thanks. Br Ben -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville Sent: Tuesday, September 01, 2009 4:31 PM To: openssl-users@openssl.org Subject: Re: Verify certificate using subordinate ca Based on what you state. There is no purpose for the root CA. What do you mean by compromised. If you publish a CA certificate to clients, it does not include the key. (normally) So the only thing a client can do is use it in the session at best. There is NO way a client can use a CA certificate to sign anything without the corresponding key. I have a chain on my website, and noone (except me, because I can access the server) is able to sign anything. Since the CAs are only used for signing and verifying and not for encrypting, if the CA keys are stored safely, there is no 'compromise' Are you distributing the keys as well? HTH Regards, Serge Fonville On Tue, Sep 1, 2009 at 2:13 PM, Yin, Ben 1. (NSN - CN/Cheng Du)ben.1@nsn.com wrote: I only want to verfiy the signature (I mean the procedure when sub ca sign the certiticate). So I guess sub ca and certification should has enough info to do it because we needn't root ca when we use sub ca to sign the certificate. Is there a way for this requirement? Thanks. Br Ben -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Yin, Ben 1. (NSN - CN/Cheng Du) Sent: Tuesday, September 01, 2009 3:06 PM To: openssl-users@openssl.org Subject: RE: Verify certificate using subordinate ca Hi Serge, My intention is to keep my root ca out of compromise. We want to use sub ca to splite the domain in the our whole network. Then, we can easy to re-sign a new sub ca and publish it if we find one domain sub ca was compromised. And if we expose the the root ca to public ,it hard to maintain if root ca was cracked. And as you said, create a new chain and let sub ca as root, I don't know how to do it. In my testing, I set verify depth to 1. I guess it will make chain only include certificate and sub ca. the testing show that the openssl still try to find the issuer of sub ca, and so the verification was failed. Here is the output: -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 20:unable to get local issuer certificate -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 27:certificate not trusted -with certificate at depth: 0 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA subject = /C=FI/ST=Tampere/L=Tampere/O=NSN/CN=lab. err 27:certificate not trusted And FYI. Here is the complete chain verfication output. -with certificate at depth: 2 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA err 0:ok -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 0:ok -with certificate at depth: 0 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA subject = /C=FI/ST=Tampere/L=Tampere/O=NSN/CN=lab. err 0:ok Thanks. Br Ben -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville Sent: Tuesday, September 01, 2009 2:14 PM To: openssl-users@openssl.org Subject: Re: Verify certificate using subordinate ca Hi, Hmm... I've had the same issue. Basically it came down to how do you know if the sub is reliable if you do not know whether to trust the root? If you do not wish to have the root as part of the chain, create a new chain where the sub is the root What is the reason you do not want to use the root in the chain check, but it should be part of the chain? HTH Regards, Serge Fonville On Tue, Sep 1, 2009 at 1:04 PM, Yin, Ben 1. (NSN - CN/Cheng Du)ben.1@nsn.com wrote: Hi, It there a way to verify certificate with out root ca? I have 4 certificate: rootca.pem is the root ca (self signed). subca.pem was signed by rootca.pem. cert1.pem cert2.pem was signed by subca.pem. I was supposed to configure the client and server using subca.pem as ca, and cert1.pem cert2.pem as certificate. It seem that openssl still try to find rootca.pem to verfiy subca.pem when handshake. But I don't what root.pem can bo accessed for keeping it safe. So It there a way to verify
Re: Verify certificate using subordinate ca
I don't see your problem honestly. Figuring out a private key is close to impossible. And stealing it, well, that is more related to security itself than to the actual key being secure or not. From what I understand, a chain works somewhat like this you --peter john --carl You talk to peter, peter is trusted by john, john is trusted by carl, you trust carl Say if you were to obsolete carl in this chain (by trusting john) john would then become the root If this is the case, why would you want to have carl at all? Thawte, verisign etc work the same way Also, why is distributing a CA cert so difficult? What is your environment? What applications are using the certs? And how do they verify the chain? Again, without the key for each CA it can't be compromised Has this actually happened or is this someone eing paranoid? Who has created the chain? I'm still not clear of the purpose of the root ca if it should not need to be trusted Regards, Serge Fonville On Tue, Sep 1, 2009 at 3:52 PM, Yin, Ben 1. (NSN - CN/Cheng Du)ben.1@nsn.com wrote: No. In our enviroment. The root CA private key is isolated and absolutly safe. Regarding the compromised, I means CA can't be trusted any more, Such as the private key was stolen some how or someone find a way to figure out private key for one CA. it easy to set up new sub ca in one domain if those compromise happened on sub ca. but if it happened on root ca, it's quite hard to fix the our whole network. Thanks. Br Ben -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville Sent: Tuesday, September 01, 2009 4:31 PM To: openssl-users@openssl.org Subject: Re: Verify certificate using subordinate ca Based on what you state. There is no purpose for the root CA. What do you mean by compromised. If you publish a CA certificate to clients, it does not include the key. (normally) So the only thing a client can do is use it in the session at best. There is NO way a client can use a CA certificate to sign anything without the corresponding key. I have a chain on my website, and noone (except me, because I can access the server) is able to sign anything. Since the CAs are only used for signing and verifying and not for encrypting, if the CA keys are stored safely, there is no 'compromise' Are you distributing the keys as well? HTH Regards, Serge Fonville On Tue, Sep 1, 2009 at 2:13 PM, Yin, Ben 1. (NSN - CN/Cheng Du)ben.1@nsn.com wrote: I only want to verfiy the signature (I mean the procedure when sub ca sign the certiticate). So I guess sub ca and certification should has enough info to do it because we needn't root ca when we use sub ca to sign the certificate. Is there a way for this requirement? Thanks. Br Ben -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Yin, Ben 1. (NSN - CN/Cheng Du) Sent: Tuesday, September 01, 2009 3:06 PM To: openssl-users@openssl.org Subject: RE: Verify certificate using subordinate ca Hi Serge, My intention is to keep my root ca out of compromise. We want to use sub ca to splite the domain in the our whole network. Then, we can easy to re-sign a new sub ca and publish it if we find one domain sub ca was compromised. And if we expose the the root ca to public ,it hard to maintain if root ca was cracked. And as you said, create a new chain and let sub ca as root, I don't know how to do it. In my testing, I set verify depth to 1. I guess it will make chain only include certificate and sub ca. the testing show that the openssl still try to find the issuer of sub ca, and so the verification was failed. Here is the output: -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 20:unable to get local issuer certificate -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 27:certificate not trusted -with certificate at depth: 0 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA subject = /C=FI/ST=Tampere/L=Tampere/O=NSN/CN=lab. err 27:certificate not trusted And FYI. Here is the complete chain verfication output. -with certificate at depth: 2 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA err 0:ok -with certificate at depth: 1 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Root CA subject = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA err 0:ok -with certificate at depth: 0 issuer = /C=fi/O=WCDMA/CN=NSN Tre WCDMA Sub1 CA subject = /C=FI/ST=Tampere/L=Tampere/O=NSN/CN=lab. err 0:ok Thanks. Br Ben -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of ext Serge Fonville Sent: Tuesday, September 01,
pkcs12 with frienlyNames seems to be erroneous
Being unable to using a PKCS#12 file created by openSSL with 3 different applications - Java jarsigner, Firefox/Thunderbird and KeyStoreBuilder of the package not-yet-commons-ssl http://juliusdavies.ca/commons-ssl/ - I think that the problem may well be attributed to an error in the PKCS#12 file. All 3 errors are due to the use of the friendlyName in the PKCS#12 file. Even so the Mozilla products don't explain why they don't accept the file contents, removing the friendlyName from the the p12 file makes it acceptable. The java utility jarsigner and KeyStorBuilder 0.3.9 issue the error message: java.io.IOException: Attribute 1.2.840.113549.1.9.20.9.20 should have a value DerInputStream.getLength(): lengthTag=32, too big OID 1.2.840.113549.1.9.20 represents PKCS-9 Attribute : friendlyName. KeyStoreBuilder even tracks the error: java.io.IOException: Attribute 1.2.840.113549.1.9.20 should have a value DerInputStream.getLength(): lengthTag=32, too big. at sun.security.pkcs12.PKCS12KeyStore.loadSafeContents(PKCS12KeyStore.java:1426) at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1291) at java.security.KeyStore.load(KeyStore.java:1201) at org.apache.commons.ssl.KeyStoreBuilder.tryJKS(KeyStoreBuilder.java:450) at org.apache.commons.ssl.KeyStoreBuilder.parse(KeyStoreBuilder.java:341) at org.apache.commons.ssl.KeyStoreBuilder.build(KeyStoreBuilder.java:98) at org.apache.commons.ssl.KeyStoreBuilder.main(KeyStoreBuilder.java:540) Even so the problem may be attributed to the applications, I suspect that the fact that it happens with 3 applications rather points to an error in the PKCS#12 file. Any ideas Regards Willy Weisz -- --- Willy Weisz European Centre for Parallel Computing at Vienna (VCPC) Institute of Scientific Computing University of Vienna Nordbergstrasse 15/C312 A-1090 Wien Tel: (+43 1) 4277 - 39424 Fax: (+43 1) 4277 - 9394 e-mail: we...@vcpc.univie.ac.at __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
jehan procaccia a écrit : I finally found it ! [proca...@anaconda ~] $ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile /etc/pki/tls/certs/new_it_root_ca10.crt -verify 3 verify depth is 3 CONNECTED(0003) depth=3 /CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr verify return:1 depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr verify return:1 depth=1 /CN=TELECOM Management SudParis class3 Certificate Authority/OU=TELECOM Management SudParis/O=TELECOM Management SudParis/C=fr verify return:1 depth=0 /C=fr/ST=Essonne/L=Evry/O=Telecom et Management SudParis/OU=s2ia/CN=svnext.int-evry.fr verify return:1 --- Certificate chain 0 s:/C=fr/ST=Essonne/L=Evry/O=Telecom et Management SudParis/OU=s2ia/CN=svnext.int-evry.fr i:/CN=TELECOM Management SudParis class3 Certificate Authority/OU=TELECOM Management SudParis/O=TELECOM Management SudParis/C=fr 1 s:/CN=TELECOM Management SudParis class3 Certificate Authority/OU=TELECOM Management SudParis/O=TELECOM Management SudParis/C=fr i:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr 2 s:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr 3 s:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr Now everything seems ok with that new root CA: http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt unfortunatly it's not completely finished :-( now on clients where I removed the original root-ca and added the new re-signed root CA ( new_it_root_ca10.crt), I have a issuer/serial problem when accessing a server configured with the old root CA. For example going to https://www-cours.it-sudparis.eu/, server which is configured with the original chain and itrootca CA root, firefox complains about : sec_error_reused_issuer_and_serial the same with seamonkey client : Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number indeed my re-signed root-ca (http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt) does have the same serial values as the original itrootca.crt $ openssl x509 -in /etc/pki/tls/certs/new_it_root_ca10.crt -text ... Serial Number: f9:bf:e3:44:a7:66:2a:a4 X509v3 Authority Key Identifier: serial:F9:BF:E3:44:A7:66:2A:A4 ... indeed I supose that when I re-signed my root CA this way: openssl x509 -signkey it_root_ca.key -set_serial 01 -clrext -extfile opensslIT.cnf -extensions v3_ca -days 5475 -in it_root_ca.crt -out new_it_root_ca10.crt Then as long as I call the original -in it_root_ca.crt in the command above , I suspect it extract the serial from it, no matter what I set with -set_serial openssl option, it does not set anything new !. then, here's my question, should I set a new serial in order to not conflict with the original one, how can I set it ? if I cannot set a new serial, then it means I should change all my server ca-chain config in one shot the same day and all my clients browsers keystore :-( ? or is there a soft and clean way to migrate smoothly from the originalm root-ca and the new one ? thanks . __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verifying a detached PEM signature
I should have included a log file for what the messages generated by the script... See attached. I also note that the signature portion of the smime formatted message matches the detached signature contents. Any advice is appreciated, -- Keith Hellman #include disclaimer.h khell...@mcprogramming.comfrom disclaimer import standard khell...@mines.edu -*- public key @ pgp.mit.edu 9FCF40FD Y!M: mcprogramming AIM/ICQ: 485403897 gtalk (xmpp jabber): mrtu...@jabber.org, jab...@mcprogramming.com -*- I would point out that linked lists, mark-and-copy garbage collection, and the Tab key are all patented too. Somebody who always carefully checked first for software patents would never write anything at all. -- Martin Pool (rsync developer) http://rsync.samba.org/rsync-and-debian/rsync-and-debian.html $ openssl smime -sign -in ./sign-script -signer ./sign-script.crt -inkey ./sign-script.key -out ./sign-script.signed $ openssl smime -verify -noverify -in ./sign-script.signed Verification successful $ openssl smime -sign -in ./sign-script -signer ./sign-script.crt -inkey ./sign-script.key -outform PEM -out ./sign-script.pemsigned $ openssl smime -verify -noverify -inform PEM -content ./sign-script -in ./sign-script.pemsigned Verification failure 10572:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:pk7_doit.c:948: 10572:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:312: signature.asc Description: Digital signature
Re: Need help with s_client
On Mon August 31 2009, Ritesh Rekhi wrote: Hi All, I want to write a SSL client which will not ack for all the data on TCP layer and then close a connection i.e I want to test the tcp close when there is unacknowledged data on socket. I tried using s_client and tried to modify the code where there is: k=SSL_read(con,sbuf,1024 /* BUFSIZZ */ ); I tried changing the buffer size and tried adding delay after first read, but looking at tcp conn on ethereal I saw that even if my client is not reading the data , the data is getting acked back. At that level, what is being ack'd is the packet, not the contents (payload). Mike I will really appreciate any ideas or tools to achieve this. Ritesh __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: add extension to an existing (signed) CA certificate
Never, ever, ever, ever, ever under any circumstances issue the same serial number twice. You tried to issue the same serial to both roots -- badbadbadbadbadDONOT. -Kyle H On Tue, Sep 1, 2009 at 8:56 AM, jehan procacciajehan.procac...@it-sudparis.eu wrote: jehan procaccia a écrit : I finally found it ! [proca...@anaconda ~] $ openssl s_client -host svnext.it-sudparis.eu -port 443 -CAfile /etc/pki/tls/certs/new_it_root_ca10.crt -verify 3 verify depth is 3 CONNECTED(0003) depth=3 /CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr verify return:1 depth=2 /CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr verify return:1 depth=1 /CN=TELECOM Management SudParis class3 Certificate Authority/OU=TELECOM Management SudParis/O=TELECOM Management SudParis/C=fr verify return:1 depth=0 /C=fr/ST=Essonne/L=Evry/O=Telecom et Management SudParis/OU=s2ia/CN=svnext.int-evry.fr verify return:1 --- Certificate chain 0 s:/C=fr/ST=Essonne/L=Evry/O=Telecom et Management SudParis/OU=s2ia/CN=svnext.int-evry.fr i:/CN=TELECOM Management SudParis class3 Certificate Authority/OU=TELECOM Management SudParis/O=TELECOM Management SudParis/C=fr 1 s:/CN=TELECOM Management SudParis class3 Certificate Authority/OU=TELECOM Management SudParis/O=TELECOM Management SudParis/C=fr i:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr 2 s:/CN=Institut TELECOM class2 Certificate Authority/OU=Institut TELECOM/O=Institut TELECOM/C=fr i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr 3 s:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr i:/CN=Institut TELECOM Root class1 Certificate Authority/O=Institut TELECOM/C=fr Now everything seems ok with that new root CA: http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt unfortunatly it's not completely finished :-( now on clients where I removed the original root-ca and added the new re-signed root CA ( new_it_root_ca10.crt), I have a issuer/serial problem when accessing a server configured with the old root CA. For example going to https://www-cours.it-sudparis.eu/, server which is configured with the original chain and itrootca CA root, firefox complains about : sec_error_reused_issuer_and_serial the same with seamonkey client : Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number indeed my re-signed root-ca (http://ca.institut-telecom.fr/pki/IT_MASTER_CA/new_it_root_ca10.crt) does have the same serial values as the original itrootca.crt $ openssl x509 -in /etc/pki/tls/certs/new_it_root_ca10.crt -text ... Serial Number: f9:bf:e3:44:a7:66:2a:a4 X509v3 Authority Key Identifier: serial:F9:BF:E3:44:A7:66:2A:A4 ... indeed I supose that when I re-signed my root CA this way: openssl x509 -signkey it_root_ca.key -set_serial 01 -clrext -extfile opensslIT.cnf -extensions v3_ca -days 5475 -in it_root_ca.crt -out new_it_root_ca10.crt Then as long as I call the original -in it_root_ca.crt in the command above , I suspect it extract the serial from it, no matter what I set with -set_serial openssl option, it does not set anything new !. then, here's my question, should I set a new serial in order to not conflict with the original one, how can I set it ? if I cannot set a new serial, then it means I should change all my server ca-chain config in one shot the same day and all my clients browsers keystore :-( ? or is there a soft and clean way to migrate smoothly from the originalm root-ca and the new one ? thanks . __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-us...@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: add extension to an existing (signed) CA certificate
well, if one takes the standard configuration of openssl, it sets the authoritykey_identifier both the hash and issuer serial, no exception for the root. comment says that pkix recommends that. I do not see this recommandation in the rfcs. at least there is a length paragraph for roots to have an exception, and nowhere it is said you must have both link types. an AKI identifies the KEY, not the certificate btw I am not sure that the issuer/serial logic is correctly implementing this in all implementations. It doesn't mean that the verifying CA certificate must have this issuer/combination, any other CA certificate with the same subject DN and same key is also ok. S my 2centimes /P __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: the format of openssl speed
Hi: 2009/8/31 Dave Thompson dave.thomp...@princetonpayments.com: From: owner-openssl-us...@openssl.org On Behalf Of loody Sent: Friday, 28 August, 2009 04:15 the above mean aes-128 cbc will use 55113.2k bytes/second while encrypting/decrypting 16btytes plain text? This build running on this machine doing aes-128-cbc operations of 16 bytes each does 55113.2k bytes/second, yes. BTW, does type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes means different length of plain text? Yes. As far as I know, aes and des are symmetric encryption, so the unit of plaintext should as big as key. No, unpadded plaintext (and ciphertext) must be a MULTIPLE of the DATA BLOCK size, not necessarily the key size. Original single DES had both data=64bits and key=64bits (but including parity, so the real key was 56bits), but this is not a requirement in general. Triple-DES (TDEA) has data=64 but key=really168 nominally192 (or in the obsolete two-key option really112 nominally128). AES has data=128 and key=128 OR 192 OR 256. (Rijndael, the algorithm used for AES, can handle other data and key sizes also, but only these sizes are standardized.) Note that there is some overhead for each operation, so e.g. 1 encrypt of 16000 bytes is faster than 1000 encrypts of 16 bytes each. That's why the aggregate throughput increases for larger data chunks. In practice you usually use padding so that any plaintext size is allowed, at the cost of making the ciphertext up to one block bigger than the plaintext. (And for CBC and CTR modes at least, you also need to transmit the IV somehow; this is often done by just prepending it to the ciphertext, making the ciphertext another block bigger.) However, these functions aren't included in the 'speed' test since they have negligible effect on performance. For *asymmetric* primitives (RSA, DSA, ECDSA) the data is limited to (somewhat less than) (part of) the key size, but you don't use asymmetric primitives directly on your data, instead you use them to encrypt a (small fixed-size) key for symmetric encryption, or sign a (small fixed-size) hash. Thanks Dave :) appreciate your help, miloody __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
