directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Updated: (DIRSERVER-1164) SSL Cert Compatibility issue with LDAPS for Outlook Clients
Date Thu, 04 Sep 2008 00:47:44 GMT


Alex Karasulu updated DIRSERVER-1164:

    Fix Version/s:     (was: 1.5.4)

This requires a CLI tool command to change the DN of the certificate and just replace it.
 So I will delay this until we have time to add this feature.

> SSL Cert Compatibility issue with LDAPS for Outlook Clients
> -----------------------------------------------------------
>                 Key: DIRSERVER-1164
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Improvement
>          Components: ldap
>    Affects Versions: 1.5.2
>            Reporter: Steve
>            Assignee: Alex Karasulu
>             Fix For: 1.5.6
> Any Outlook Version will simply refuse the service to LDAPS on a default apacheds installation.
> The SSL certificate has to match the hostname exactly - if it is empty or you do not
connect using
> the DNS name - outlook will simply refuse the connection even if the cert itself is trusted.
> The Standard Apache 1.5.2 distribution should work out of the box with Outlook Clients
for using LDAPS - 
> the only catch is the SSL certificate which is automatically generated by apacheDS -
it is neither
> trusted by outlook - nor does it contain a valid common name (the DNS name of the server)
it seems.
> The first issue can of course not be resolved by the auto key generation when you startup
the server - but maybe the DNS address of the certificate.
> Even then - there needs to be a way to easily extract the generated public key so that
you can manually trust it on windows clients.
> This issue only applies to Outlook Clients - Thunderbird/LDAPBrowser and Co will ask
the user if they want to connect to untrusted sites.
> Alternatively - there should be an option for admins to simply change the SSL key to
a valid/trusted one - in 1.52 the only way i found so far
> for modifying the SSL key is programatically this way :
> EntryOperationContext adminEntry = new EntryOperationContext(
> 				directoryService.getRegistries(), PartitionNexus.getAdminName());
> 		if (directoryService.getPartitionNexus().hasEntry(adminEntry)) {
> 			KeyStore store = // load some store from p12 for example
> 			KeyPair keyPair = // load some keypair from store
> 			Attributes entry = new BasicAttributes();
> 			PrivateKey privateKey = keyPair.getPrivate();
> 			entry.put(TlsKeyGenerator.KEY_ALGORITHM_AT, privateKey
> 					.getAlgorithm());
> 			entry.put(TlsKeyGenerator.PRIVATE_KEY_AT, privateKey.getEncoded());
> 			entry.put(TlsKeyGenerator.PRIVATE_KEY_FORMAT_AT, privateKey
> 					.getFormat());
> 			PublicKey publicKey = keyPair.getPublic();
> 			entry.put(TlsKeyGenerator.PUBLIC_KEY_AT, publicKey.getEncoded());
> 			entry.put(TlsKeyGenerator.PUBLIC_KEY_FORMAT_AT, publicKey
> 					.getFormat());
> 			Certificate cert = store.getCertificate(alias);
> 			entry.put(TlsKeyGenerator.USER_CERTIFICATE_AT, cert.getEncoded());
> 			List<Modification> items = ModifyOperationContext.createModItems(
> 					ServerEntryUtils.toServerEntry(entry, PartitionNexus
> 							.getAdminName(), directoryService.getRegistries()),
> 					ModificationOperation.REPLACE_ATTRIBUTE);
> 			directoryService.getPartitionNexus().modify(
> 					new ModifyOperationContext(
> 							directoryService.getRegistries(), PartitionNexus
> 									.getAdminName(), items));

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message