Recently researching on the Direct Project. Wanna try the different ways that Direct Project supported to make the certificates management.
The certificates management includes public certificates management and private certificates management.
And these two repository should be separately maintained. You wont want to expose your private key...
First, I try to setup LDAP as the 'PrivateCertStore'.
http://api.nhindirect.org/java/site/gateway/1.2/users-guide/smtp-depl-wsconfig.html#SMTP_Agent_WebService_Configuration
Based on the document of direct project above about the configuration of LDAP, I config the Direct WS. And in the mean time, setup the LDAP server using ApacheDS. Run the James.
Issue1: The property 'PrivateStoreLDAPCertPassphrase' must be set, even though you are not using 'pkcs12' type private certificates. And this value must be set to the psw that to access the LDAP directory, the same as the 'PrivateStoreLDAPPassword'. And after opening the remote debug, found this value is used to access the keystore file...This does not make sense. But the truth is, you need to set it. :)
Issue2: The certificates that Direct Project Generated from the tool cetGen are not base64 encoded. Fine, the Direct WS also accept certs that hasn't been Base64 encoded. But if you use LDAP to store your private certificates, issue comes. Based on the RFC-2849, LDAP will mistake the content of the private key/ p12 certificate. So, the certificates that saved into LDAP must be Base64 encoded.
I went through the Direct Project Jave code, find that when parsing the cert data from LDAP, the private cert's data has the Base64 decode procedure before the data is converted to Certificates.
But, I didn't find document on this in Direct Wiki. Hope the instruction could have more detail, it'll save other user's time. And also, the tool should support this feature, otherwise, users need to generate tool themselves to encode each certificates that they generated.
So, Base64 encode the private certificates(p12 file) before you put them into LDAP, only in this way, your direct can read right value back.
Second, I try to setup LDAP as the 'PublicCertStore'.
http://api.nhindirect.org/java/site/gateway/1.2/users-guide/smtp-depl-wsconfig.html#SMTP_Agent_WebService_Configuration
Issue3: In the doc, there's no option for setting LDAP as public cert store. But when you look into the code, there's one option, called 'PublicLDAP'. If you add this value into the 'PublicCertStore' setting. For example, if you set "PublicCertStore = WS, PublicLDAP". Then when your Direct search recipient's public cert, it'll search on the recipient domain's LDAP server. This requires that recipient must set up their LDAP server and make it support 'anonymous access'.
Initially I put all the cert entries under 'ou=user, ou=system'. Then it does not work, the sender cannot find the recipient's public cert. I open the remote debug, find that Direct only search for base.
"ctls.setSearchScope(SearchControls.OBJECT_SCOPE);"
This means that it only search dn one level under base(which are the name contexts attributes in the base), which only access to "ou=system", I have to move all my certs from 'ou=user, ou=system' to 'ou=system'. Then Direct works fine.
So, if you wanna setup your LDAP server, you have to put all your cert entries under the level one entry under base. Like this:
OR, create one customized partition under base as entry for all your public certs.
And, need to mention that, the public cert must be saved in 'userCertificate' attribute, and the mail attribute must be set to the domain address or email address.
And the objectClass must be 'inetOrgPerson'. These values are hard-coded as search criteria in Direct Project.
And the objectClass must be 'inetOrgPerson'. These values are hard-coded as search criteria in Direct Project.
In the 'DIRECT CERTIFICATE DISCOVERY TEST IMPLEMENTATION INSTRUCTION GUIDE'
Office of the National Coordinator for Health Information Technology
Version 1.0
April 27, 2012
They setup their LDAP in the structure like this:
They use DNS mixed LDAP, I guess it all goes to DNS for searching public cert instead of LDAP.
Reference:
http://www.ldapguru.info/ldap/ldap-search-best-practices.html(Good introducing level article for LDAP search)
No comments:
Post a Comment