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 v1&v3 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 List openssl-users@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
