Current situation:
We do a POST to a certain url using HTTPS/SSL. For this to work my (former) colleague posted this question: Java HTTPS client certificate authentication
So basicly we have a keystore in .p12 format and the truststore is a .jks file.
We have no control over the server that receives our POST request.
Issue:
The server admins have provided us with some new .der files because their old certificate was about to expire.
As I’m fairly new to SSL certificates and keytool– and openssl-commands I have no idea how to proceed from here.
1) Is it necessary to generate new .p12 and .jks files? Or do I only need to generate a new .jks file?
2) How do I generate these files from a .der certificate? I have found some websites with the most keytool/openssl commands but I haven’t been able to successfully generate what I need.
The last command I tried (to no avail) was:
keytool -storepass dsmserver -keystore c:\temp\newkeystore.jks -importcert -alias "c:\temp\newcert.der" -trustcacerts
Wait, which certificate expired? If it was theirs, there shouldn’t have been any need to send you a new file (after all, you don’t have to update your browser when, say, stackoverflow.com’s SSL certificate expires and they install a new one). If you’re doing mutual authentication (client certificate authentication), then there are four certificates involved: your certificate, their certificate, the certificate of the authority that signed your certificate, and the certificate of the authority that signed their certificate. They send you their certificate and you check to see that it was properly signed by a certificate authority that you trust (that’s what the truststore is for – it’s a list of the certificate authorities that you trust to sign certificates from their side). Subsequently, you send your certificate and they check to see that it was properly signed by a certificate authority that they trust. (Of course, all of this is automatically done for you behind the scenes in JSSE by the SSL handshake procedure)
Remember, a certificate is a (signed) assertion that such-and-such name is identified by a particular public key. So if their certificate expired, they’ll generate a new one, get it signed by a CA that you already trust, and replace the old one with this one. When your software (automatically, as part of the behind-the-scenes SSL handshake) gets the new one, it will check to see who the signer (“issuer”) was and if it’s in your list of trusted authorities (and properly signed). If this checks out, you’ll accept it automatically. They don’t need to send you anything out-of-band to make this happen, unless they’re changing certificate authorities and you don’t already trust the new one. If so, you can use
If, on the other hand, your certificate is the one that expired, then they shouldn’t be sending you anything unrequested. Instead, you should be generating a CSR via:
This will update the keystore with a new private key and create a file named “request.csr” which you should then send to them (or to a CA that’s in their truststore) for a signature. They will respond with a signed certificate which you will then import back into your keystore using:
If I had to guess, it looks like they tried to perform these three steps for you, and tried to send you the certificate and the corresponding private key, which is invalid – Java will (rightly!) try its best to stop you from importing that because the private key itself was tainted when they sent it over an untrusted channel (e-mail, I presume?) This defeats the purpose of PKI – nobody should ever have access to your private key except for you.