RE: Question on OpenSSL encryption
I have struggled with SSL/TLS in the past. Good list of books. I checked amazon's table of contents and it looks like Joshua Davies has written a more comprehensive book with lots of code. Clearly it seems to me to be a better book with good reviews. Rolf Oppliger's book is more than twice the cost of the former and did not seem to have code. The former seems to be more technical than the latter. I would like to buy Davies. Neither is specifically about OpenSSL. Anybody agree ? Thanks, Mohan From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Ashok C Sent: Monday, January 09, 2012 8:15 PM To: openssl-users@openssl.org Cc: richard.koenn...@ts.fujitsu.com Subject: Re: Question on OpenSSL encryption Thanks Richard, What I am looking would be any good book which gives details about SSL communication like use of certificates, verification of certificates, APIs to examine certificates, certificate revocation concepts/SSL APIs for that, etc. Regds, Ashok 2012/1/9 Richard Könning richard.koenn...@ts.fujitsu.com Am 09.01.2012 13:10, schrieb Ashok C: Hi, In addition to the online material, are there any good books which we can refer to understand openSSL better? Both conceptually as well as from the API/code perspective. We hear of the Network Security with OpenSSL by John Viega as one good reference. But it was published in 2002. Any good new books which can be used? Well, the questions of the original poster weren't OpenSSL specific, but targeted SSL/TLS in general, for this Eric Rescorla's book SSL and TLS: Building and Designing Secure Systems is the better book. Sadly being from the year 2000 it is somewhat outdated too, but nevertheless a good introduction to SSL/TLS. For a description of the OpenSSL API afaik the book from Viega et al. is still the most detailed book, despite being somewhat outdated. For newer versions of TLS (i.e. 1.1 and beyond) one should check newer TLS books, e.g. the ones from Joshua Davies or Rolf Oppliger. Until now i had none of the two books in my hands so i can't you tell more about the books, but maybe a visit at Amazon or similar book traders will give you at least a detailed content description. Ciao, Richard __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org DISCLAIMER: ==The information contained in this e-mail message may be privileged and/or confidential and protected from disclosure under applicable law. It is intended only for the individual to whom or entity to which it is addressed as shown at the beginning of the message. If the reader of this message is not the intended recipient, or if the employee or agent responsible for delivering the message is not an employee or agent of the intended recipient, you are hereby notified that any review, dissemination,distribution, use, or copying of this message is strictly prohibited. If you have received this message in error, please notify us immediately by return e-mail and permanently delete this message and your reply to the extent it includes this message. Any views or opinions presented in this message or attachments are those of the author and do not necessarily represent those of the Company. All e-mails and attachments sent and received are subject to monitoring, reading, and archival by the Company.==
SSL documentation
Hi, Is there any material available that shows flows of one-way/two-ssl and different types of CA architectures ? We use two-way SSL and generate CSR's and update expired certificates and we are aware of the basic points. I have browsed the NIST website. Thanks, Mohan DISCLAIMER: ==The information contained in this e-mail message may be privileged and/or confidential and protected from disclosure under applicable law. It is intended only for the individual to whom or entity to which it is addressed as shown at the beginning of the message. If the reader of this message is not the intended recipient, or if the employee or agent responsible for delivering the message is not an employee or agent of the intended recipient, you are hereby notified that any review, dissemination,distribution, use, or copying of this message is strictly prohibited. If you have received this message in error, please notify us immediately by return e-mail and permanently delete this message and your reply to the extent it includes this message. Any views or opinions presented in this message or attachments are those of the author and do not necessarily represent those of the Company. All e-mails and attachments sent and received are subject to monitoring, reading, and archival by the Company.==
RE: Replace renewed intermediate certificate in the keystore chain: in Java
Hi, Not sure why I mixed up the order earlier but this procedure works. If the old leaf is first in the .pem file followed by the new intermediate and the old root the intermediate is renewed successfully. I have to use the already existing chain alias. I think this is what should have worked for you too ? Thanks, Mohan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Saturday, May 14, 2011 7:44 AM To: openssl-users@openssl.org Subject: RE: Replace renewed intermediate certificate in the keystore chain: in Java From: owner-openssl-us...@openssl.org On Behalf Of Mohan Radhakrishnan Sent: Friday, 13 May, 2011 00:35 So I tried that procedure. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. 1. If my lowermost leaf is first in the .pem file then a new alias is created and the certificate is imported. Not what I want. A new alias with the wrong name (what did you specify)? A second alias with the same name (should be impossible)? A new alias of type trustedcert and the privatekey is deleted? 2. If the new intermediate is first in the .pem file then the intermediate is renewed successfully. But the lowermost leaf is gone from the keystore. It is being deleted. The chain now has the root and the intermediate but the public key certificate. It is broken. I assume you mean root and intermediate but NOT LEAF. In which order i.e. which is [1] and which is [2] etc.? Both of these work for me on 6u13 and 6u24, the oldest and newest I can conveniently test now. A few stabs in the dark: 1. I assume(d) you are using the standard Sun/Oracle providers with no customization (e.g. JRE/lib/ext, lib/security/java.security). 2. All my test CA certs are v1, because that's easier to generate. If your certs are from a public CA, or even a decent private one, they're almost certainly v3 with extensions. In my experience Java gets both v1v3 right but conceivably this is a case it doesn't. I'll try to test that later if I have more time. 3. keytool -importcert is documented to work for these cases, except the doc page describes chains only using PKCS#7 not concatenation. But in practice concatenation always has worked for me. I don't know any standard OpenSSL way to create cert-only PKCS#7, although a program to do so would be pretty simple (and ontopic!). Thanks, Mohan -Original Message- From: Mohan Radhakrishnan Sent: Friday, May 13, 2011 9:28 AM Actually the procedure is similar 1. Use Keytool and convert JKS to PKCS12. 2. Use OpenSSL to convert PKCS12 contents to pem. Now this has the private key and the entire chain. That wasn't clear, at least to me ... 3. Use open source Java tool to build a new keystore *after replacing the intermediate with the one received*. ... and you didn't mention that additional tool before. Clear now. List the keytool contents and verify the expiry date has changed. That's enough. If you keytool -importcert from a cert/chain matching a privatekey it becomes (replaces) the cert/chain for that privatekey; if not it becomes a trustedcert entry instead. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. I think this procedure is different. I think you mean that I have to export the lowermost leaf and then add the new intermediate and import it back using the same alias of the chain it will work. Will try this. Yes, as above. (To be exact, the alias of the privatekey entry which *contains* the chain, but the chain is what you see listed.) (If you also concatenate and thus include the root, JSSE will serve it, but there's no point in doing that, since the client(s) shouldn't trust a root cert they don't already have in truststore or equivalent.) This point is not clear. The root is not touched at all either in the client's store or the server's store. My point was that you said you have the root in the existing/old privatekey entry, and seemed to want to keep it there. keytool -importcert replaces the entire chain, so to keep the root in the updated entry, I need to add the root to the concatenated file, and so would you if this method worked for you at all. But there's no reason to have a root in any privatekey entry. In case you don't already know some relevant basics: *Any* SSL verifying party can never actually use a root sent by its peer; the verifier must have the root trust locally. A Java client must have a trustedcert entry for the server's root, and for client auth the server must have the client's root (assuming standard/default trustmanager). In some cases the client and server certs use the same root so this distinction doesn't matter, but in many cases it does. As a default truststore, JSSE uses JRE/lib/security/cacerts
RE: Replace renewed intermediate certificate in the keystore chain: in Java
I also saw this message Top-level certificate in reply: Other certificate details are printed ... is not trusted. Install reply anyway? [no]: yes Certificate reply was installed in keystore Thanks, Mohan -Original Message- From: Mohan Radhakrishnan Sent: Monday, May 16, 2011 9:43 AM To: 'openssl-users@openssl.org' Subject: RE: Replace renewed intermediate certificate in the keystore chain: in Java Hi, Not sure why I mixed up the order earlier but this procedure works. If the old leaf is first in the .pem file followed by the new intermediate and the old root the intermediate is renewed successfully. I have to use the already existing chain alias. I think this is what should have worked for you too ? Thanks, Mohan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Saturday, May 14, 2011 7:44 AM To: openssl-users@openssl.org Subject: RE: Replace renewed intermediate certificate in the keystore chain: in Java From: owner-openssl-us...@openssl.org On Behalf Of Mohan Radhakrishnan Sent: Friday, 13 May, 2011 00:35 So I tried that procedure. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. 1. If my lowermost leaf is first in the .pem file then a new alias is created and the certificate is imported. Not what I want. A new alias with the wrong name (what did you specify)? A second alias with the same name (should be impossible)? A new alias of type trustedcert and the privatekey is deleted? 2. If the new intermediate is first in the .pem file then the intermediate is renewed successfully. But the lowermost leaf is gone from the keystore. It is being deleted. The chain now has the root and the intermediate but the public key certificate. It is broken. I assume you mean root and intermediate but NOT LEAF. In which order i.e. which is [1] and which is [2] etc.? Both of these work for me on 6u13 and 6u24, the oldest and newest I can conveniently test now. A few stabs in the dark: 1. I assume(d) you are using the standard Sun/Oracle providers with no customization (e.g. JRE/lib/ext, lib/security/java.security). 2. All my test CA certs are v1, because that's easier to generate. If your certs are from a public CA, or even a decent private one, they're almost certainly v3 with extensions. In my experience Java gets both v1v3 right but conceivably this is a case it doesn't. I'll try to test that later if I have more time. 3. keytool -importcert is documented to work for these cases, except the doc page describes chains only using PKCS#7 not concatenation. But in practice concatenation always has worked for me. I don't know any standard OpenSSL way to create cert-only PKCS#7, although a program to do so would be pretty simple (and ontopic!). Thanks, Mohan -Original Message- From: Mohan Radhakrishnan Sent: Friday, May 13, 2011 9:28 AM Actually the procedure is similar 1. Use Keytool and convert JKS to PKCS12. 2. Use OpenSSL to convert PKCS12 contents to pem. Now this has the private key and the entire chain. That wasn't clear, at least to me ... 3. Use open source Java tool to build a new keystore *after replacing the intermediate with the one received*. ... and you didn't mention that additional tool before. Clear now. List the keytool contents and verify the expiry date has changed. That's enough. If you keytool -importcert from a cert/chain matching a privatekey it becomes (replaces) the cert/chain for that privatekey; if not it becomes a trustedcert entry instead. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. I think this procedure is different. I think you mean that I have to export the lowermost leaf and then add the new intermediate and import it back using the same alias of the chain it will work. Will try this. Yes, as above. (To be exact, the alias of the privatekey entry which *contains* the chain, but the chain is what you see listed.) (If you also concatenate and thus include the root, JSSE will serve it, but there's no point in doing that, since the client(s) shouldn't trust a root cert they don't already have in truststore or equivalent.) This point is not clear. The root is not touched at all either in the client's store or the server's store. My point was that you said you have the root in the existing/old privatekey entry, and seemed to want to keep it there. keytool -importcert replaces the entire chain, so to keep the root in the updated entry, I need to add the root to the concatenated file, and so would you if this method worked for you at all. But there's no reason to have a root in any privatekey entry. In case you don't already know some relevant basics: *Any* SSL verifying party can never actually use a root sent
RE: Replace renewed intermediate certificate in the keystore chain
Hi, Actually the procedure is similar 1. Use Keytool and convert JKS to PKCS12. 2. Use OpenSSL to convert PKCS12 contents to pem. Now this has the private key and the entire chain. 3. Use open source Java tool to build a new keystore *after replacing the intermediate with the one received*. List the keytool contents and verify the expiry date has changed. That's enough. If you keytool -importcert from a cert/chain matching a privatekey it becomes (replaces) the cert/chain for that privatekey; if not it becomes a trustedcert entry instead. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. I think this procedure is different. I think you mean that I have to export the lowermost leaf and then add the new intermediate and import it back using the same alias of the chain it will work. Will try this. (If you also concatenate and thus include the root, JSSE will serve it, but there's no point in doing that, since the client(s) shouldn't trust a root cert they don't already have in truststore or equivalent.) This point is not clear. The root is not touched at all either in the client's store or the server's store. Thanks, Mohan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Friday, May 13, 2011 6:41 AM To: openssl-users@openssl.org Subject: RE: Replace renewed intermediate certificate in the keystore chain From: owner-openssl-us...@openssl.org On Behalf Of Mohan Radhakrishnan Sent: Thursday, 12 May, 2011 00:04 I think I have been able to replace only the intermediate certificate which has a different validity period. I believe this can be done because what the intermediate certificate is signing is still valid. Only the expiry date is changing and it is being renewed. And the new intermediate is for the same key(pair) as the old, as surmised upthread? 1. Root is valid 2. Sub root or intermediate is replaced 3. Public key certificate is valid. No new CSR is required. I have done this by using keystore commands. From your example below, Java jks using keytool? I exported all the contents of the existing keystore including the private key as a .pem and then replaced only the new intermediate. This was imported back. Now when I run the command Are you sure? Java keytool can't export a privatekey to any kind of pem -- but it can export the CERT FOR a privatekey = the first or only cert in a privatekey entry to either DER or PEM (slightly confusingly called -rfc). That's enough. If you keytool -importcert from a cert/chain matching a privatekey it becomes (replaces) the cert/chain for that privatekey; if not it becomes a trustedcert entry instead. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. (If you also concatenate and thus include the root, JSSE will serve it, but there's no point in doing that, since the client(s) shouldn't trust a root cert they don't already have in truststore or equivalent.) Java keytool CAN convert a jks privatekey (AND chain) to PKCS12 by doing -importkeystore with -deststoretype PKCS12. See below. Keytool -list -v -keystore store I can see the chain with the new intermediate in the middle. We are going to test the SSL part to validate. Has anyone does this to the Java keystore with OpenSSL ? OpenSSL cannot manipulate jks directly. OpenSSL can operate on PKCS12. If you use keytool to convert to PKCS12 (or, less likely, have PKCS12 already) you can use OpenSSL to unpack, modify, and rebuild the PKCS12, which keytool can then convert back to jks. But why bother? __ 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: Replace renewed intermediate certificate in the keystore chain
So I tried that procedure. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. 1. If my lowermost leaf is first in the .pem file then a new alias is created and the certificate is imported. Not what I want. 2. If the new intermediate is first in the .pem file then the intermediate is renewed successfully. But the lowermost leaf is gone from the keystore. It is being deleted. The chain now has the root and the intermediate but the public key certificate. It is broken. Thanks, Mohan -Original Message- From: Mohan Radhakrishnan Sent: Friday, May 13, 2011 9:28 AM To: 'openssl-users@openssl.org' Subject: RE: Replace renewed intermediate certificate in the keystore chain Hi, Actually the procedure is similar 1. Use Keytool and convert JKS to PKCS12. 2. Use OpenSSL to convert PKCS12 contents to pem. Now this has the private key and the entire chain. 3. Use open source Java tool to build a new keystore *after replacing the intermediate with the one received*. List the keytool contents and verify the expiry date has changed. That's enough. If you keytool -importcert from a cert/chain matching a privatekey it becomes (replaces) the cert/chain for that privatekey; if not it becomes a trustedcert entry instead. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. I think this procedure is different. I think you mean that I have to export the lowermost leaf and then add the new intermediate and import it back using the same alias of the chain it will work. Will try this. (If you also concatenate and thus include the root, JSSE will serve it, but there's no point in doing that, since the client(s) shouldn't trust a root cert they don't already have in truststore or equivalent.) This point is not clear. The root is not touched at all either in the client's store or the server's store. Thanks, Mohan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Friday, May 13, 2011 6:41 AM To: openssl-users@openssl.org Subject: RE: Replace renewed intermediate certificate in the keystore chain From: owner-openssl-us...@openssl.org On Behalf Of Mohan Radhakrishnan Sent: Thursday, 12 May, 2011 00:04 I think I have been able to replace only the intermediate certificate which has a different validity period. I believe this can be done because what the intermediate certificate is signing is still valid. Only the expiry date is changing and it is being renewed. And the new intermediate is for the same key(pair) as the old, as surmised upthread? 1. Root is valid 2. Sub root or intermediate is replaced 3. Public key certificate is valid. No new CSR is required. I have done this by using keystore commands. From your example below, Java jks using keytool? I exported all the contents of the existing keystore including the private key as a .pem and then replaced only the new intermediate. This was imported back. Now when I run the command Are you sure? Java keytool can't export a privatekey to any kind of pem -- but it can export the CERT FOR a privatekey = the first or only cert in a privatekey entry to either DER or PEM (slightly confusingly called -rfc). That's enough. If you keytool -importcert from a cert/chain matching a privatekey it becomes (replaces) the cert/chain for that privatekey; if not it becomes a trustedcert entry instead. If you export your existing leaf cert, and concatenate it with the new intermediate and import that combination, it will work. (If you also concatenate and thus include the root, JSSE will serve it, but there's no point in doing that, since the client(s) shouldn't trust a root cert they don't already have in truststore or equivalent.) Java keytool CAN convert a jks privatekey (AND chain) to PKCS12 by doing -importkeystore with -deststoretype PKCS12. See below. Keytool -list -v -keystore store I can see the chain with the new intermediate in the middle. We are going to test the SSL part to validate. Has anyone does this to the Java keystore with OpenSSL ? OpenSSL cannot manipulate jks directly. OpenSSL can operate on PKCS12. If you use keytool to convert to PKCS12 (or, less likely, have PKCS12 already) you can use OpenSSL to unpack, modify, and rebuild the PKCS12, which keytool can then convert back to jks. But why bother? __ 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 List
Replace renewed intermediate certificate in the keystore chain
Hi, I have checked my keystore and truststore and the intermediate certificate alone is going to expire. I have received a renewed intermediate pem. I believe it is common practice to just replace an expiring intermediate certificate instead of the root. The root will expire in2025. I have replaceed only the intermediate certificate in the trust store using this command. keytool -import -trustcacerts -alias root -file certificate -keystore keystore.jks Now I have a question. The trust store contains the intermediate certificate with a clear alias and I could access it. The key store seems to have the entire chain. Not sure if it is possible to update only the intermediate certificate here. How do I update the intermediate certificate and still maintain the chain in the keystore using Openssl or the Java keystore commands ? Thanks, Mohan
RE: Replace renewed intermediate certificate in the keystore chain
Hi, I think I have been able to replace only the intermediate certificate which has a different validity period. I believe this can be done because what the intermediate certificate is signing is still valid. Only the expiry date is changing and it is being renewed. 1. Root is valid 2. Sub root or intermediate is replaced 3. Public key certificate is valid. No new CSR is required. I have done this by using keystore commands. I exported all the contents of the existing keystore including the private key as a .pem and then replaced only the new intermediate. This was imported back. Now when I run the command Keytool -list -v -keystore store I can see the chain with the new intermediate in the middle. We are going to test the SSL part to validate. Has anyone does this to the Java keystore with OpenSSL ? Thanks, Mohan -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Erik Tkal Sent: Wednesday, May 11, 2011 10:32 PM To: openssl-users@openssl.org Subject: RE: Replace renewed intermediate certificate in the keystore chain No, that should not be true - as long as the subject name of the issuer does not change and the key pair is reused, then any previously issued certificates should still verify against the issuer. Note that the thumbprint will be different, in case that is used anywhere to track the cert. Erik Tkal Juniper OAC/UAC/Pulse Development -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of John R Pierce Sent: Wednesday, May 11, 2011 12:47 PM To: openssl-users@openssl.org Subject: Re: Replace renewed intermediate certificate in the keystore chain On 05/10/11 11:03 PM, Mohan Radhakrishnan wrote: Hi, I have checked my keystore and truststore and the intermediate certificate alone is going to expire. as I understand it (vaguely at best), if the intermediate certfiicate expires, that invalidates any certificates it generated, so you will need to regenerate and replace all child certificates too. ... __ 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: Windows Certificate Store with OpenSSL Certificate
Hi, Have a question. Is this the Windows native store for CA certificates ? Which MS help doc. are you referring ? We want a secure storage facility for all our certificates but we don't to buy a separate product. Thanks, Mohan On Wed, Sep 8, 2010 at 5:10 AM, Dongsheng Song dongsheng.s...@gmail.com wrote: Are you test with 2008/win7 ? My self-signed certificate can automatically goto 'Trusted Root Certification Authorities' on XP/2k3 box, but not 2008 box. If the answer is 'YES', could you share the configuration ? Because I compared my self-signed certificate with microsoft 2010 ROOT CA, no valuable difference. Thanks, Dongsheng On Wed, Sep 8, 2010 at 01:59, Jakob Bohm jb-open...@wisemo.com wrote: On 07-09-2010 09:59, Dongsheng Song wrote: Hi, When I install my self-signed certificate to 'Certificate Store' of Windows 2008, if I select 'Automatically select the certificate store based on the type of certificate', then the self-signed certificate will be in the 'Intermediate Certification Authorities', not 'Trusted Root Certification Authorities'. How can I create self-signed certificate with correct certificate TYPE ? Regards, Dongsheng Note that this did NOT happen with the self-signed CA root cert that I created with openssl (via a GUI front end) for our internal network CA. (Used for such boring tasks as SSL certificates for domain controllers etc.). It has the following attributes (anonymised here): Certificate: Data: Version: 3 (0x2) Serial Number: f8:dd:1a:38:49:01:61:a4 Signature Algorithm: sha1WithRSAEncryption Issuer: C=XX, L=Somecity, O=OurCompany, CN=OurCompany Inc. Validity Not Before: Apr 19 18:41:02 2010 GMT Not After : Apr 16 18:41:02 2020 GMT Subject: C=XX, L=Somecity, O=OurCompany, CN=OurCompany Inc. Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (4096 bit) Modulus (4096 bit): (Omitted) Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 9E:37:BE:96:A4:55:F4:B9:6A:27:85:0F:F8:A2:6F:EE:E4:3D:B4:35 X509v3 Authority Key Identifier: keyid:9E:37:BE:96:A4:55:F4:B9:6A:27:85:0F:F8:A2:6F:EE:E4:3D:B4:35 DirName:/C=XX/L=Somecity/O=OurComapany/CN=OurCompany Inc. serial:F8:DD:1A:38:49:01:61:A4 X509v3 Basic Constraints: critical CA:TRUE Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA X509v3 Issuer Alternative Name: EMPTY Netscape Comment: WiseMo Internal CA Netscape CA Revocation Url: https://SomeInternalServer/somename.crl Netscape Revocation Url: https://SomeInternalServer/somename.crl X509v3 Key Usage: critical Certificate Sign, CRL Sign Signature Algorithm: sha1WithRSAEncryption (omitted) __ 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: Certificate roll
Hi, Ok. I am just trying to understand the rules for refreshing an intermediate certificate or any other certificate that has expired or has been compromised without breaking the SSL connection. Thanks, Mohan On Thu, Aug 19, 2010 at 9:06 PM, Sam Jantz sjan...@gmail.com wrote: Mohan, Unless the certificate is self-signed there is no way to change the information without having to invalidate it by signing it yourself anyway. You would either have to get a new certificate from the same (or other trusted) CA, and install that one, or (if it is self signed) generate a new certificate and sign it yourself with the same private key as before, and then start using the new one. So I am not familiar with the Java interface with SSL, but in c at least you would create this new cert using the X509 library. Hope this helps shed some light. -Sam On Thu, Aug 19, 2010 at 6:24 AM, Mohan Radhakrishnan radhakrishnan.mo...@gmail.com wrote: Hi John, Yes. We do use SSL certificates. You can consider me a newbie. I am just trying to understand the ways to roll an intermediate or any other certificate that is going to expire soon without causing an outage. Is that possible at all ? (e.g) If a certificate is compromised I am trying to roll to a new certificate without bringing down my java application. Thanks, Mohan On Thu, Aug 19, 2010 at 2:11 PM, John Doe jd...@yahoo.com wrote: From: Mohan Radhakrishnan radhakrishnan.mo...@gmail.com Is there any material that shows how to roll to new certificates using OpenSSL ? I am looking for a test case to understand how this works. Anyone know about this ? Did you try to google something like generate certificate openssl or openssl certificates howto...? JD __ 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 -- Sam Jantz Software Engineer __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Certificate roll
Hi, Is there any material that shows how to roll to new certificates using OpenSSL ? I am looking for a test case to understand how this works. Anyone know about this ? Thanks, Mohan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate roll
Hi John, Yes. We do use SSL certificates. You can consider me a newbie. I am just trying to understand the ways to roll an intermediate or any other certificate that is going to expire soon without causing an outage. Is that possible at all ? (e.g) If a certificate is compromised I am trying to roll to a new certificate without bringing down my java application. Thanks, Mohan On Thu, Aug 19, 2010 at 2:11 PM, John Doe jd...@yahoo.com wrote: From: Mohan Radhakrishnan radhakrishnan.mo...@gmail.com Is there any material that shows how to roll to new certificates using OpenSSL ? I am looking for a test case to understand how this works. Anyone know about this ? Did you try to google something like generate certificate openssl or openssl certificates howto...? JD __ 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
Various forms of two-way SSL
Hi, Two-way SSL is sometimes very confusing. I know that a keystore and a truststore are always involved in two-way SSL communication. Are there various forms of two-way SSL ? 1. We want to open a server socket and also act as a client. 2. Similary the server also can be a client because the message exchange is initiated either way. Can any one clarify this ? I assume that in this case both the client as well as the server have to generate a CSR each. Thanks, Mohan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Windows Certificate Store Private Key
Hi, Please ignore if this question belongs else where but it looks like the OP is storing and retrieving SSL certificate from a Windows store. I have been looking for ways to use the Windows store to secure SSL certificates and keys and SFTP keys. Is windows or any other method recommended for storage of keys and certificates not created by Windows ? We just cut a CD with the keys and hand it over to the custodian as recommended by PCI but we want a storage server. I know that RedHat has a PKI server but we already have windows and the number of keys is less. Thanks, Mohan On Thu, Jun 24, 2010 at 9:45 PM, Harshvir Sidhu hvssi...@gmail.com wrote: Hey thanks all for the reply. Stephen: Yes i have to do client authentication, Is there some sample available that demonstrates how can i use capi engine for the same? Thanks. // Harshvir On Thu, Jun 24, 2010 at 7:29 AM, Dr. Stephen Henson st...@openssl.org wrote: On Wed, Jun 23, 2010, Harshvir Sidhu wrote: Hi All, I am trying to read Certificates and Private Key from Windows Certificate Store and then using them in OpenSSL. I am able to read Certificates but i am having trouble with reading Private Key. Have anyone done this before, any pointers will be great. Thanks. Depends on what you want to do with the key. If you want to use it for SSL/TLS client authentication then you can use the CryptoAPI ENGINE to pick an appropriate certficate and key and use them directly. You just have to set the SSL client authentication ENGINE to capi. For other purposes you can load the private key from the capi ENGINE using ENGINE_load_private_key(). The string you pass by default is a substring of the certificate name e.g. if it has CN=steve then steve will do. 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 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
Compare two certificate chains
Hi, Are there any options in OpenSSL to compare two certificate chains based on some parameters. Could the comparison parameters be fingerprints, validity, algorithm and other features like CRL url's ? Thanks, mohan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Cipher suite not available
Hi, We see this message no available certificates or key corresponding to the cipher suites even before establishing a handshake. It is a mutual handshake. So keystores and truststores are there on both sides. Algorithms are RSA. Could this be caused due to a RSA bit size mismatch ? Would this error message be caused if one pair of keystore and truststore use 2048 and the other pair of keystore and truststore use 1024 ? Please share your experience. Thanks, Mohan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Cipher suite not available
Possibly not. I meant that there could be 3 problems 1. Algorithm mismatch 2. Certificate imported in an incorrect keystore. 3. No trusted certificate chain. Trying to home in on one of the problems. Thanks, Mohan On Fri, Dec 4, 2009 at 4:24 PM, Mohan Radhakrishnan radhakrishnan.mo...@gmail.com wrote: Hi, We see this message no available certificates or key corresponding to the cipher suites even before establishing a handshake. It is a mutual handshake. So keystores and truststores are there on both sides. Algorithms are RSA. Could this be caused due to a RSA bit size mismatch ? Would this error message be caused if one pair of keystore and truststore use 2048 and the other pair of keystore and truststore use 1024 ? Please share your experience. Thanks, Mohan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Cipher suite not available
We diagnosed the problem. Our keystore is missing the private key. Java code to export the private key failes. Even IBM keyman shows only certificates. It is not as if somebody can delete the private key from the keystore ? Mohan On Sat, Dec 5, 2009 at 6:28 AM, Dave Thompson dave.thomp...@princetonpayments.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Mohan Radhakrishnan Sent: Friday, 04 December, 2009 05:54 We see this message no available certificates or key corresponding to the cipher suites even before establishing a handshake. It is a mutual handshake. So keystores and truststores are there on both sides. Algorithms are RSA. Do you mean before starting the handshake (before connection), or on connection before/without the handshake succeeding? If the former, it's definitely not due to the other party. It must be between the local config and the local keystore. (Truststore only matters for authenticating the other party.) If it happens on connection, it *could* still be a local problem that just doesn't get detected and reported until the connection attempt tries to use it. Which party and what software is reporting this, and exactly what does it say, and what if anything does the other party say about the connection attempt (e.g. does it get an SSL alert)? Could this be caused due to a RSA bit size mismatch ? Would this error message be caused if one pair of keystore and truststore use 2048 and the other pair of keystore and truststore use 1024 ? Please share your experience. No. RSA as used in SSL/TLS allows any (reasonable) size, and 1k and 2k are definitely reasonable. Each party normally chooses its own key. A truststore must match the cert(s) used by the OTHER party(ies). For example, if server is authenticated by a selfsigned cert with RSA 3k key, client must have *that* cert in its truststore, and thus *that* cert must use RSA 3k. It may have other certs in its truststore with different keytype/size, for the same or other parties. (Of course there's no point in having certs for, and if selfsigned using, PK algorithms you won't negotiate.) If the server is authenticated by a CA-signed cert, the client truststore must contain the *CA* cert, with the CA keytype/size, which may differ from the server's (or client's) and often does. (The CA's key *should* be cryptographically stronger than the entities it certifies, but SSL does not require or enforce this.) __ 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
CRL's
Hi, I have a CA-signed certificate chain and whenever the SSL handshake is going on I see 'UnparseableException' related to CRL URL's. This particular URL seems to point to the CA's LDAP. What exactly is going on here ? The handshake succeeds but I am trying to understand if this is an automated way of revoking the certificates ? Looking for something to read about this. Thanks, Mohan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
.pem certificate loading issue
I have an ASCII text file with a chain of certificates. I had earlier sent a CSR and got these certificates back from the CA. When I opened the ASCII file I see some text before and after ---BEGIN CERTIFICATE-- and --END CERTIFICATE-- I removed this test because they were file names like CASubroot.pem.txt, CArootpem.txt etc. I tried to use openssl to convert these .pem certificates to .der. It didn't work. I am sure I am doing something wrong. How do I load these certificates into the Java KeyStore ? Since these are certificates signing my CSR I am going to load them back to the Java KeyStore( Not the TrustStore ). Can anyone throw some light on this procedure ? Thanks, Mohan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: .pem certificate loading issue
What is the link between the existing key's alias and the alias used while importing the CA-root and sub-root certificates ? The CA-root and sub-root certificates have been imported with new aliases. The old alias throws an error. Thanks, Mohan On Thu, Aug 27, 2009 at 2:35 PM, Mohan Radhakrishnanradhakrishnan.mo...@gmail.com wrote: I have an ASCII text file with a chain of certificates. I had earlier sent a CSR and got these certificates back from the CA. When I opened the ASCII file I see some text before and after ---BEGIN CERTIFICATE-- and --END CERTIFICATE-- I removed this test because they were file names like CASubroot.pem.txt, CArootpem.txt etc. I tried to use openssl to convert these .pem certificates to .der. It didn't work. I am sure I am doing something wrong. How do I load these certificates into the Java KeyStore ? Since these are certificates signing my CSR I am going to load them back to the Java KeyStore( Not the TrustStore ). Can anyone throw some light on this procedure ? Thanks, Mohan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: .pem certificate loading issue
Not it does not look like I need OpenSSL. The following Java command could import the entire chain. keytool -import -alias visaftpsflux -file visacertificateedited.cer -trustcacerts -keystore FSSNABMAPSVISA.jks -storepass password Further testing is required. Mohan On Thu, Aug 27, 2009 at 4:24 PM, Mohan Radhakrishnanradhakrishnan.mo...@gmail.com wrote: What is the link between the existing key's alias and the alias used while importing the CA-root and sub-root certificates ? The CA-root and sub-root certificates have been imported with new aliases. The old alias throws an error. Thanks, Mohan On Thu, Aug 27, 2009 at 2:35 PM, Mohan Radhakrishnanradhakrishnan.mo...@gmail.com wrote: I have an ASCII text file with a chain of certificates. I had earlier sent a CSR and got these certificates back from the CA. When I opened the ASCII file I see some text before and after ---BEGIN CERTIFICATE-- and --END CERTIFICATE-- I removed this test because they were file names like CASubroot.pem.txt, CArootpem.txt etc. I tried to use openssl to convert these .pem certificates to .der. It didn't work. I am sure I am doing something wrong. How do I load these certificates into the Java KeyStore ? Since these are certificates signing my CSR I am going to load them back to the Java KeyStore( Not the TrustStore ). Can anyone throw some light on this procedure ? Thanks, Mohan __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
