RE: Replace renewed intermediate certificate in the keystore chain: in Java
From: owner-openssl-us...@openssl.org On Behalf Of Mohan Radhakrishnan Sent: Monday, 16 May, 2011 00:13 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. (To be exact: the alias for the existing *privatekey* entry, which *includes* the chain.) I think this is what should have worked for you too ? Yes that did work for me, and now for you. Another way that works and I prefer is old leaf plus new intermediate and NO root, because as I explained there's no benefit to having the root in the privatekey entry. But you were already using with-root, and I guess you want to continue doing so, and it does no harm. snip earlier __ 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: 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: 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 which is installed containing about 50 public-CA certs. If you use that default and one of those CAs, you don't need to make any change to have the required root entry(s). If you use your own JKS, it can contain both privatekey entries (used as keymanager material) and trustedcert entries (used as truststore), but each entry is one or the other. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager
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
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
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
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
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
