I am trying to validate a certificate against java key store and this is the code I am using is as below. If it completes succesfully then I assume the validation has gone through correctly, else if an exception is thrown, then the validation fails.
My concern is:
Is the code below sufficient to validate a certificate? As in is there something I am missing here (Like checking the data signed by the computer sending me the certificate?)?
2. Should the signature contained within the certificate be verified? If yes, how?
Thanks in advance for the response!
pradeep
// To check the validity of the dates
cert.checkValidity();
//Check the chain
CertificateFactory cf = CertificateFactory.getInstance("X.509");
List<X509Certificate> mylist = new ArrayList<X509Certificate>();
mylist.add(cert);
CertPath cp = cf.generateCertPath(mylist);
PKIXParameters params = new PKIXParameters(getTrustStore());
params.setRevocationEnabled(false);
CertPathValidator cpv =
CertPathValidator.getInstance(CertPathValidator.getDefaultType());
PKIXCertPathValidatorResult pkixCertPathValidatorResult =
(PKIXCertPathValidatorResult) cpv.validate(cp, params);
Normally, a certificate will be issued by an intermediate issuing authority, not a "root" authority (which is all that should be in your trust store). Most protocols encourage sending a "chain" of certificates, not just the entity's certificate.
You should add all of the intermediate certs so that a complete chain can be formed.
In order to be certain that the certificate is still valid, you should not disable revocation checks. If you don't want to retrieve a CRL (which can be large), the issuer may offer OCSP support. But, this has to be enabled in the Java runtime by setting certain system properties.
If the path validator returns successfully, you don't need to check anything else. If the certificate is not valid, an exception will be raised.
Also, an explicit check on the validity date is unnecessary. This occurs during validation (using the current time, unless you specify a time via the PKIXParameters).
For a more extensive discussion of validation, including sample code, see a previous answer of mine.
If you're happy with the default trust settings (as they would be used for the default SSLContext), you could build an X509TrustManager independently of SSL/TLS and use if to verify your certificate independently.
It would look like this:
TrustManagerFactory trustManagerFactory =
TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init((KeyStore)null);
// you could use a non-default KeyStore as your truststore too, instead of null.
for (TrustManager trustManager: trustManagerFactory.getTrustManagers()) {
if (trustManager instanceof X509TrustManager) {
X509TrustManager x509TrustManager = (X509TrustManager)trustManager;
x509TrustManager.checkServerTrusted(...);
}
}
(You should also check the server's identity and the certificate match, see RFC 6125 (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)).)
What you are doing here is verifying if a certificate (in your example cert) has been signed (directly) by any of the trusted CA's in the truststore.
Additionally you check for expiration but no revocation checking is performed.
So if the cert has not been signed by any of the trusted CA's you will get an exception.
So the code is sufficient to verify if cert has been signed by any of the trusted CAs
If you are refering to server authentication, then the code in the post is not sufficient.
This code just verifies that a specific certificate is signed by a trusted CA.
You have no indication though if the "entity" that send you this certificate is actually the owner of the certificate (i.e. they own the private key associated with this certificate).
This is part of the SSL authentication, where e.g. the client sends the ClientKeyExchange message encrypted with the remote server's public key and is certain that if the other party is fake then it will not be possible to decrypt the message
Related
I have googled around all over the place for this, and asked in other communities, and I keep getting forwarded to the oracle document that discusses the spec. However, that document more covers the naming of methods, and the overall architecture, and doesn't actually come up with a way to discuss how to actually write some code to check if an x509 cert is revoked or not.
Maybe this one is just way over my head? But I would definitely appreciate if someone could just help me out with a snippet, I have been banging my head against a wall on this for about a week.
Every CA publishes the list of the certificates it has revoked.
This list includes the serial number of the certificates and the revocation date
to get the url of the certificate revocation list (CRL) follow the below steps
open the certificate
go to Details Tab and find the field "CRL Distribution Point" in the details list
It will show you the value something like this
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=mscrl.microsoft.com/pki/mscorp/crl/msitwww2.crl
URL=crl.microsoft.com/pki/mscorp/crl/msitwww2.crl
So in your code you need to download these files and check for the certificate serial number in them to see if it's revoked or not
Find below the sample code for it
public class CertVerification {
public static void main(String[] args) throws Exception {
String certificatePath = "C:\\Users\\user1\\Desktop\\test.cer";
CertificateFactory cf = CertificateFactory.getInstance("X509");
X509Certificate certificate = null;
X509CRLEntry revokedCertificate = null;
X509CRL crl = null;
certificate = (X509Certificate) cf.generateCertificate(new FileInputStream(new File(certificatePath)));
URL url = new URL("http://<someUrl from certificate>.crl");
URLConnection connection = url.openConnection();
try(DataInputStream inStream = new DataInputStream(connection.getInputStream())){
crl = (X509CRL)cf.generateCRL(inStream);
}
revokedCertificate = crl.getRevokedCertificate(certificate.getSerialNumber());
if(revokedCertificate !=null){
System.out.println("Revoked");
}
else{
System.out.println("Valid");
}
}
}
Please See
These lists are updated periodically
You can get these Revocation URL's from the certificate as well, i have just given an example
This is just a basic example to give you a head start
Update
I found this sample class to check certificate, it also verifies with the CRL issued by the certificate's CA and certification chain, so you don't need to provide the CRL url as well
https://svn.cesecore.eu/svn/ejbca/branches/Branch_3_2_3_utf8/ejbca/doc/samples/ValidateCertUseCRL.java
A Certification Authority publish the status of the certificates using Online Certificate Service Protocol (OCSP) and Certificate Revocation Lists (CRL).
Check the revocation of a certificate involves several steps:
Extract the CRL distribution point and OCSP url from AIA extension included in the X509Certificate
Download the CRL and check if the serial number of your certificate is included. Verify the signing certificate of the CRL and ensure is trusted (root CA in your truststore)
Query online the OCSP service sending the serial number and the issuer to get the status. Check the signature of the OCSP response and ensure signing certificate is trusted (root CA in your truststore).
Certificate is revoked if it is present in CRL or OCSP status is revoked. OCSP is recommended over CRLs, but it usual to query both service because could be down.
As you can see the process is not simple at all. Check if a certificate is valid may consists in several invocations to OCSP service, downloading the certificate chain, verify signature of signing certificate of the CRLs and OCSP responses, and finally verify that the CA is trusted
So I recommend not to use Java native methods directly if you are not going to take into account all these factors
You can use BouncyCastle to manage CRL and query OCSP, but a better decision would be to use the SD-DSS framework (it uses also BouncyCastle), that pretty encapsulates all this stuff.
Github SD-DSS: https://github.com/esig/dss
Documentation: http://dss.nowina.lu/doc/dss-documentation.html
Example
Full example to validate a certificate checking revocation. Omit the steps of loading the trusted source and intermediates if you only want to check revocation
//Load the certification chain, including the intemediate certificates and the trusted root.
CertificateToken issuerCert = DSSUtils.loadCertificate("/trusted.crt");
CommonTrustedCertificateSource trustedCertificateSource = new CommonTrustedCertificateSource();
trustedCertificateSource.addCertificate(issuerCert);
CommonCertificateSource adjunctCertificateSource = new CommonCertificateSource();
CertificateToken intermediateCert = DSSUtils.loadCertificate("/intermediate.cer");
adjunctCertificateSource.addCertificate(intermediateCert);
//Load the certificate to verify
CertificateToken toValidateX509Certificate = DSSUtils.loadCertificate("/toValidate.crt");
CertificateToken toValidateCertificateToken = adjunctCertificateSource.addCertificate(toValidateX509Certificate);
//Configure the certificate verifier using the trust store and the intermediate certificates
//OnlineOCSPSource and OnlineCRLSource will invoke the OCSP service and CRL
//distribution point extracting the URL from the certificate
CertificateVerifier certificateVerifier = new CommonCertificateVerifier();
certificateVerifier.setTrustedCertSource(trustedCertificateSource);
certificateVerifier.setAdjunctCertSource(adjunctCertificateSource);
certificateVerifier.setCrlSource(new OnlineCRLSource());
certificateVerifier.setOcspSource(new OnlineOCSPSource());
//Perform validation
CertificatePool validationPool = certificateVerifier.createValidationPool();
SignatureValidationContext validationContext = new SignatureValidationContext(validationPool);
validationContext.addCertificateTokenForVerification(toValidateCertificateToken);
validationContext.validate();
//Get revocation status
Boolean isRevoked = toValidateCertificateToken.isRevoked();
RevocationToken revocationToken = toValidateCertificateToken.getRevocationToken();
This question already has answers here:
What is a NullPointerException, and how do I fix it?
(12 answers)
Closed 6 years ago.
I have hit a dead end using the OpenSAML support for preparing a SAML Payload to accomplish a SSO transaction with another service that I am working with. I receive a NullPointerException that is thrown after I use the SecurityHelper.prepareSignatureParams() routine. I have a Stacktrace, but it wold be pretty ugly to append.
Let me first say what I was able to do...
For the purposes of learning the technology and to make sure it would work, I was able to successfully build a SAML payload, sign it using a Certificate and a Private Key that was stored in a Java Key Store file that I created locally on my workstation using the Keytool program with the -genkeypair option.
As I understand things, my JKS file contains a Self Signed Certificate and a Private Key. I was able to open the JKS file, gather the Certificate and the Private Key to build a Signing Certificate. The Signing Certificate was used to sign the SAML Payload that I created You'll see how I did this if you look at the code samples that I'll append.
What isn't working...
I want to use the same SAML support to sign my SAML Payload using a Trusted Certificate that I have for my website that I received from GoDaddy. To do this, I installed the Trusted Certificate into my webserver's keystore at: '\Program Files\Java\jre1.8.0_102\lib\security\cacerts'. I understand that the cacerts file is the KeyStore for our webserver. I installed the Trusted Certificate using the Keytool -importcert command. One big difference is that the Trusted Certificate DOESN'T have a Private Key. So when preparing the Signing Certificate using the Open SAML support, I am not able to add a Private Key to the Credential object (because I don't have one).
When attempting the above for the Trusted Certificate, I am able to get to the part where I am preparing the Signature Parms (SecurityHelper.prepareSignatureParams()). That's where I get the Null Pointer.
If you could take a look at the code that I am using. I am including the code (that signs my payload successfully) that reads from the local JKS file and also the code (that gets the Null Pointer Exception) when I try to using the Trusted Certificate on the server (both cases). There's not much different between the two cases:
// Signing process using OpenSAML
// Get instance of an OpenSAML 'KeyStore' object...
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
// Read KeyStore as File Input Stream. This is either the local JKS
// file or the server's cacerts file.
File ksFile = new File(keyStoreFileName);
// Open an Input Stream with the Key Store File
FileInputStream ksfInputStream = new FileInputStream(ksFile);
// Load KeyStore. The keyStorePassord is the password assigned to the keystore, Usually 'changeit'
// before being changed.
keyStore.load(ksfInputStream, keyStorePassword);
// Close InputFileStream. No longer needed.
ksfInputStream.close();
// Used to get Entry objects from the Key Store
KeyStore.PrivateKeyEntry pkEntry = null;
KeyStore.TrustedCertificateEntry tcEntry = null;
PrivateKey pk = null;
X509Certificate x509Certificate = null;
BasicX509Credential credential = null;
// The Java Key Store specific code...
// Get Key Entry From the Key Store. CertificateAliasName identifies the
// Entry in the KeyStore. KeyPassword is assigned to the Private Key.
pkEntry = (KeyStore.PrivateKeyEntry) keyStore.getEntry(certificateAliasName, new KeyStore.PasswordProtection(keyPassword));
// Get the Private Key from the Entry
pk = pkEntry.getPrivateKey();
// Get the Certificate from the Entry
x509Certificate = (X509Certificate) pkEntry.getCertificate();
// Create the Credential. Assign the X509Certificate and the Privatekey
credential = new BasicX509Credential();
credential.setEntityCertificate(x509Certificate);
credential.setPrivateKey(pk);
// The Trusted Certificate specific code...
// Accessing a Certificate that was issued from a trusted source - like GoDaddy.com
//
// Get Certificate Entry From the Key Store. CertificateAliasName identifies the Entry in the KeyStore.
// There is NO password as there is no Private Key associate with this Certificate
tcEntry = (TrustedCertificateEntry) keyStore.getEntry(certificateAliasName, null);
// Get the Certificate from the Entry
x509Certificate = (X509Certificate) tcEntry.getTrustedCertificate();
// Create the Credential. There is no Provate Ley to assign into the Credential
credential = new BasicX509Credential();
credential.setEntityCertificate(x509Certificate);
// Back to code that is not specific to either method...
//
// Assign the X509Credential object into a Credential Object. The BasicX509Credential object
// that has a Certificate and a Private Key OR just a Certificate added to it is now saved as a
// Cendential object.
Credential signingCredential = credential;
// Use the OpenSAML builder to create a signature object.
Signature signingSignature = (Signature) Configuration.getBuilderFactory().getBuilder(Signature.DEFAULT_ELEMENT_NAME).build Object(Signature.DEFAULT_ELEMENT_NAME);
// Set the previously created signing credential
signingSignature.setSigningCredential(signingCredential);
// Get a Global Security Configuration object.
SecurityConfiguration secConfig = Configuration.getGlobalSecurityConfiguration();
// KeyInfoGenerator. Not sure what this is, but the example I am working from shows
// this being passed as null.
String keyInfoGeneratorProfile = "XMLSignature";
// Prepare the Signature Parameters.
//
// This works fine for the JKS version of the KeyStore, but gets a Null Pointer exception when I run to the cacerts file.
SecurityHelper.prepareSignatureParams(signingSignature, signingCredential, secConfig, keyInfoGeneratorProfile <or null>);
// I need to set into the SigningSignature object the signing algorithm. This is required when using the TrustedCertificate
signingSignature.setSignatureAlgorithm(SignatureConstants.ALGO_ID_SIGNATURE_RSA_SHA256);
// This is my code that builds a SAML Response. The SAML Payload contains data
// about the SSO session that I will be creating...
Response samlResponse = createSamlResponse.buildSamlResponseMessage();
// Sign the Response using the Certificate that was created earlier
samlResponse.setSignature(signingSignature);
// Get the marshaller factory to marshall the SamlResponse
MarshallerFactory marshallerFactory = Configuration.getMarshallerFactory();
Marshaller responseMarshaller = marshallerFactory.getMarshaller(samlResponse);
// Marshall the Response
Element responseElement = responseElement = responseMarshaller.marshall(samlResponse);
// Sign the Object...
Signer.signObject(signingSignature);
NOTE: My attempt to sign a SAML Payload was modeled after an OPENSAML example that I found here: https://narendrakadali.wordpress.com/2011/06/05/sign-assertion-using-opensaml/
Hoping that someone can show me the error of my ways or what I am missing.
Thanks for any suggestions.
EDIT (01/26/2016)
I was able to get past the NULL pointer I was receiving while preparing the Signature Params (SecurityHelper.prepareSignatureParams()). Code changes included updating my xmlsec.jar file to version 2.0.8 (xmlsec-2.0.8.jar) and I explicitly setting the signature algorithm to SHA256 when using the Trusted Certificate (from GoDaddy). See my code example for the use of:
signingSignature.setSignatureAlgorithm(SignatureConstants.ALGO_ID_SIGNATURE_RSA_SHA256);
The above changes allows the SAML payload to be built and sent to the connection endpoint.
However, I am still not establishing the SSO connection to my endpoint.
Here's what I see happening:
During processing while the SAML payload is being constructed and specifically, the SAML payload's Signature is being signed:
Signer.signObject(signature);
I get an an error message from SAML:
ERROR: org.opensaml.xml.signature.Signer - An error occured computing the digital signature
The stack trace (just the ending portion):
org.apache.xml.security.signature.XMLSignatureException: Sorry, you supplied the wrong key type for this operation! You supplied a null but a java.security.PrivateKey is needed.
at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineInitSign(SignatureBaseRSA.java:149)
at org.apache.xml.security.algorithms.implementations.SignatureBaseRSA.engineInitSign(SignatureBaseRSA.java:165)
at org.apache.xml.security.algorithms.SignatureAlgorithm.initSign(SignatureAlgorithm.java:238)
at org.apache.xml.security.signature.XMLSignature.sign(XMLSignature.java:631)
at org.opensaml.xml.signature.Signer.signObject(Signer.java:77)
I searched the error messages, but I am not coming up with much.
I don't understand the root of the error message - That the wrong key type was supplied (null) and that OpenSAML seems to be expecting a java.Security.PrivateKey.
When using the Trusted Certificate, I don't have a Private Key, Correct? How would I be able to provide a Private Key? In the case of the Trusted Certificate I read a Trusted Certificate (TrustedCertificateEntry) from the KeyStore. The TrustedCertificateEntry object allows me to access the Certificate, but there's no method for obtaining a Private Key (as well there shouldn't be).
However, when I use my Self Signed Certificate to perform the signing operation, I understand that I do have both the Certificate (the Public Key) and the Private Key contained in the JKS file (the KeyStore). I think that's why when I read from the JKS file, I am able to read a Private Key Entry (KeyStore.PrivateKeyEntry) that has methods for accessing both the Public Key (the Certificate) and the Private Key.
What am I missing about the Trusted Certificate case? The OpenSAML support seems to be expecting a Private key to be able to compute the Signature.
In the case of the Trusted Certificate, is there a way to package the original Private Key into my Key Store (along with the Trusted Certificate)? I am not sure if this is what is normally done or even possible.
Hopefully some guidance as to what I am doing here, Please!
EDIT (01/26/2017) - 2 to provide additional detail.
I'll share a portion of the SAML payload that gets sent...
In the case of the Self Signed Certificate, I see a SignatureValue tag and a X509Certificate tag. Both have binary data included within the begin and end of the tag.
In the case of the Trusted Certificate, I've got an empty Signature Value tag that looks like:
<ds:SignatureValue/>
The Certificate tag is still present and contains the certificate bytes.
So, looking at the error I see from OpenSAML, it is more obvious that it can't compute a Signature using the data that is available in the Trusted Certificate.
Ok, this quite a long question. As I understand the root of the problem is the message "Sorry, you supplied the wrong key type for this operation! You supplied a null but a java.security.PrivateKey is needed." You are trying to sign a message using a public key. This is not possible. Just looking logically on it, signing using a public key would not provide any proof that the signer is intended as it is available to everyone.
What you need to do is sign using a private key. in your case you have generated a public and private key on you computer, then sent CSR to the CA and recieved a certificate signed by the CA.
You should use the privat key from you local computer to sign the message and send the CA signed certificate to the recipient so they can use it to confirm your signature.
In this blog post of mine I explain how to obtain credentials, including the private key from a Java keystore.
I have a X509 certificate (java.security.cert.X509Certificate) and I need to verify it. The trusted anchor is already in system default certstore ( jre\lib\security\cacerts ) but I could populate it into something else if needed. The certificate is not a SSL certificate.
My first idea was to use Java's trust manager as I am already using HTTPs with server certificates issued by the same CA. But it seems that this can be used only for SSL certifictaes as it provides only checkServerTrusted and checkClientTrusted. For sake of completness, this is my attempt:
X509TrustManager x509TrustManager=null;
trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
trustManagerFactory.init((KeyStore)null);
for (TrustManager trustManager : trustManagerFactory.getTrustManagers())
{
if (trustManager instanceof X509TrustManager)
{
x509TrustManager = (X509TrustManager)trustManager;
}
}
java.security.cert.X509Certificate x509 = .... get certificate ...
x509TrustManager.checkServerTrusted(new java.security.cert.X509Certificate[]{x509}, "RSA");
This does all I need but in addition it checks whether the certificate is valid for SSL server (or client if I use checkClientTrusted) and that obviously fails.
Is there any simple way how to specify the cert and/or key usage for the trust manager or at least a way how to disable the check (I can do it myself).
In the future I would like to use OCSP or CRL list to check the actual state of the certificate.
I have an Android application that calls web services over SSL. In production we will have normal SSL certificates that are signed by a trusted CA. However, we need to be able to support self-signed certificates (signed by our own CA).
I have successfully implemented the suggested solution of accepting self-signed certificates but this will not work due to the risk of man in the middle attacks. I then created a trustmanager that validates that the certificate chain was in fact signed by our CA.
The problem is I have to bypass the normal SSL validation - the application will now only speak to a server that has one of our self-signed certificates installed.
I am a bit lost, I've googled extensively but can't find anything. I was hoping to find a way of programmatically adding our CA to the trust store on the device as this would be the least intrusive way of dealing with the issue.
What I want to achieve:
1. Full standard support for normal SSL certificates.
2. Additional support for self-signed certificates signed by our own CA.
Any advice?
You haven't posted any code, so I can't be sure what you actually did. However, I'll assume that you're setting up a SSLContext using only your custom X509TrustManager subclass. That's fine, but what you can do is have your custom trust manager implementation also chain to the built-in trust managers. You can do this while setting up your trust manager; something like this should work:
private List<X509TrustManager> trustManagers = new ArrayList<X509TrustManager>();
public MyCustomTrustManager() {
TrustManagerFactory tmFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmFactory.init((KeyStore)null);
for (TrustManager tm : tmFactory.getTrustManagers()) {
if (tm instanceof X509TrustManager)
trustManagers.add((X509TrustManager)tm);
}
}
So now your custom trust manager has a list of all the built-in trust managers. In your override of checkServerTrusted(), you'll want to loop through the built-in trust managers and check each one by calling checkServerTrusted() on each one in turn. If none of them trust the certificate, you can apply your own cert checking. If that passes, you can return normally. If not, just throw a CertificateException as you'd otherwise do.
EDIT: Adding the below about doing things like host name verification.
You can also verify that the hostname in the certificate matches what you expect it to be. You'll want to pass in the valid hostname in your constructor for your custom trust manager and stash it in the class. Your checkServerTrusted() method will get passed an array of X509Certificate. Many "chains" will consist of just a single cert, but others will have several, depending on how the cA signed your cert. Either way, the first cert in the array should be "your" cert that you want to compare against.
After you check for basic cert validity using the trust managers, you'll then want to do something like this:
Principal subjectDN = chain[0].getSubjectDN();
String subjectCN = parseDN(subjectDN.getName(), "CN");
if (this.allowedCN.equals(subjectCN)) {
// certificate is good
}
The implementation of parseDN() is left up to you. subjectDN.getName() will return a comma-separated list of key-value pairs (separated by =), something like C=US,ST=California,L=Mountain View,O=Google Inc,CN=www.google.com. You want the CN ("Common Name") value for your hostname comparison. Note that if you have a wildcard cert, it'll be listed as something like *.example.com, so you'll need to do more than a simple equals match in that case.
I am working on an older IBM iSeries (IBM-i, i5OS, AS/400, etc), with a Java 5 JVM (Classic, not ITJ J9) on O/S version V5R3M0.
Here is the scenario in a nutshell:
I created a key-store of type JKS using Portecle 1.7 (Note: I did try converting my key-store to JCEKS but that was rejected as an unsupported format, so it appears that JKS is the only option with the iSeries machine (at least the version I am on).
I then created a key-pair and CSR and sent the CSR to Thawte to be signed.
I imported the signed certificate from Thawte successfully using the PKCS#7 format to import the entire certificate chain, which included my certificate, the Thawte intermediary and the Thawte server root.
This all worked as expected.
However, when I ran up the JVM, configured properly to point to the store and supply it's password (which I have done in the past with self-signed certificates created in Portecle for testing), and try to start my web server on 443, I get the following security exception:
java.security.KeyStoreException: Cannot store non-PrivateKeys
Can anyone tell me where I went wrong, or what I should check next?
The "Cannot store non-PrivateKeys" error message usually indicates you are trying to use secret symmetric keys with a JKS keystore type. The JKS keystore type only supports asymmetric (public/private) keys. You would have to create a new keystore of type JCEKS to support secret keys.
As it turns out, this was a subtle problem, and it's worth giving the answer here in case someone else has something similar.
The TLDR answer is that I did not check that my key and certificate were not null and as a result attempted to add a null key and certificate to a key-store. The longer answer follows.
The way we have our web server set up to use SSL, specifically to support our user's typical configuration where the IP address is used to configure the web site listen address rather than a DNS name, is that it locates the certificate in the master key-store using the alias, and creates an ephemeral key-store containing just the certificate for that web site, using that key-store to configure an SSL context and an SSL socket factory, like so:
// CREATE EPHEMERAL KEYSTORE FOR THIS SOCKET USING THE DESIRED CERTIFICATE
try {
final char[] BLANK_PWD=new char[0];
SSLContext ctx=SSLContext.getInstance("TLS");
KeyManagerFactory kmf=KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
Key ctfkey=mstkst.getKey(svrctfals,BLANK_PWD);
Certificate[] ctfchn=mstkst.getCertificateChain(svrctfals);
KeyStore sktkst;
sktkst=KeyStore.getInstance("jks");
sktkst.load(null,BLANK_PWD);
sktkst.setKeyEntry(svrctfals,ctfkey,BLANK_PWD,ctfchn);
kmf.init(sktkst,BLANK_PWD);
ctx.init(kmf.getKeyManagers(),null,null);
ssf=ctx.getServerSocketFactory();
}
catch(java.security.GeneralSecurityException thr) {
throw new IOException("Cannot create server socket factory using ephemeral keystore ("+thr+")",thr);
}
Notice that it uses a blank password for extracting the private key and certificates from the master key-store. That was my problem - I had, out of habit from using keytool, created the private key-pair with a password (the same password as the key-store).
Because I had a password on the certificate, the key and certificate were not extracted, and null was passed to sktkst.setKeyEntry(svrctfals,ctfkey,BLANK_PWD,ctfchn); However, setKeyEntry checks the passed Key using instanceof and concludes (correctly) that null is not an instanceof PrivateKey, resulting in the misleading error I was seeing.
The corrected code checks that a key and certificate are found and sends appropriate errors:
// CREATE EPHEMERAL KEYSTORE FOR THIS SOCKET USING THE DESIRED CERTIFICATE
try {
final char[] BLANK_PWD=new char[0];
SSLContext ctx=SSLContext.getInstance("TLS");
KeyManagerFactory kmf=KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
Key ctfkey=mstkst.getKey(svrctfals,BLANK_PWD);
Certificate[] ctfchn=mstkst.getCertificateChain(svrctfals);
KeyStore sktkst;
if(ctfkey==null) {
throw new IOException("Cannot create server socket factory: No key found for alias '"+svrctfals+"'");
}
if(ctfchn==null || ctfchn.length==0) {
throw new IOException("Cannot create server socket factory: No certificate found for alias '"+svrctfals+"'");
}
sktkst=KeyStore.getInstance("jks");
sktkst.load(null,BLANK_PWD);
sktkst.setKeyEntry(svrctfals,ctfkey,BLANK_PWD,ctfchn);
kmf.init(sktkst,BLANK_PWD);
ctx.init(kmf.getKeyManagers(),null,null);
ssf=ctx.getServerSocketFactory();
}
catch(java.security.GeneralSecurityException thr) {
throw new IOException("Cannot create server socket factory using ephemeral keystore ("+thr+")",thr);
}
Instead of using an ephemeral keystore, you could handle everything within a single SSLContext.
You would need to initialise your SSLContext using an custom X509KeyManager instead of using the one given by the default KeyManagerFactory. In this X509KeyManager,chooseServerAlias(String keyType, Principal[] issuers, Socket socket) should return a different alias depending on the local address obtained from the socket.
This way, you wouldn't have to worry about copying the private key from one keystore to another, and this would even work for keystore types from which you can't extract (and thus copy) but only use the private key, e.g. PKCS#11.