EJBCA, J2EE PKI Certificate Authority

Hello,
I've imported a openssl sub-ca (not self-signed) into ejbca and have been able to create end-entities etc.. My problem is that I want to use the created certificates for sasl-external login into ldap. For that to work I need to be able to verify the created certificates against the public certificate of the ca. This doesn't work. I think the test is to use <code> openssl verify -CAfile ca cert.pem </code><p/> which works fine for certificates created directly with openssl. Any ideas what needs to be done? THanks

Richard

The file 'ca' needs to contain both the ca-cert from ejbca and the root certificate I think, since your CA is not self-signed. openssl needs to create the whole chain to be able to verify the certificate.

/Tomas

Thanks,

Well that doesn't seem to be the problem. I've added the chain components to a single file as well as adding the ca certs to the ca-bundle.crt file. The error I get back is : error 20 at 0 depth lookup: unable to get local issuer certificate

One thing I do notice is that the order of components in the issuer of the daughter cert is the reverse of that of the subject for the ca cert. So that subject is /C=xx/ST=xx/L=xxx in the ca and listed with CN first in the daughter cert. I checked and the ca cert I gave is not changed by ejbca.

Would this problem go away if I could force openssl to create certs with the attributes in the same order? or is that an irrelevant issue?

Hello,
Another aside on this: You can create a certificate request from a x509 certificate with openssl x509 and I tried that. The resultant certificate when signed by the openssl CA is quite different from the certificate signed by ejbca even though the CA's are identical.

Besides the reversal of the attributes in the issuer name, ejbca uses a different algorithm (sha1 v md5) and the openssl has an attribute called DirName. I'm not sure what is relevant so...... Possibly I could change my openssl.cnf file to make it compatible to ejbca. Thanks

Well, it seems to be working and I'm pretty confident that I can get the sasl-external on openldap to work with these certificates. In the end I did two things: First in the CertTools.java file I changed the dnOptions to Reverse (btw, that a was real clever coding idea) and then secondly (and probably more relevant) I created an external CA from within the adminweb exported out the certificate request then signed it with the system root using openssl. I then added the certificate to the ca-bundle.crt file (openssl verify -CAfile ca-bundle.crt xx.pem) and it worked.

I wonder if the command line via ca.sh needs to be corrected, but as long as there is a reasonable method that is great.

Yes, I was thinking that the ca-bundle.crt file needs to contain a full chain. Great that it works.

Btw: reversal of the order of DN should not be relevant in theory, in practice some stupid software (internet explorer) can barf if the ordering os wrong.
In the end-user certificate the issuer part should be in the same order as the subject part of the CA-cert though, at least ejbca is supposed to be coded that way. You have to examine the certs using the same software (i.e. OpenSSL) though, as the presentation is software dependent, openssl writes it in one order and java in another for example. The internal asn.1 coding is what matters (though it should not).
The flag in CertTools was created since some old legacy software cares about ordering.

SHA1 is the preffered hash-algorithm these days since MD5 has security issues and should not be used in modern systems.

The DirName extension is definately optional, you can produce a wide range of optional exentsions in ejbca for ocsp verifcation, crl distributions points etc etc. It's configured in certificate profiles.

Cheers,
Tomas