In my last post I made a mistake. I made the mistake of believing that R9 changed something for the better that it apparently does not, and that when the product gets updated. so do the tools. My bad. Basically I'm moron.

First the good news, Domino 9.0.1 FP4 does work with Active Directory 2012 with TLS1.2. Woohoo.

I was under the impression that you could now cross certify an internet certificate into the Domino Directory and it would now be trusted. I could have sworn I read this somewhere, but for the life of me I can't find it. See, previously you'd have to add the Active Directory's root certificate (in this case the Windows CA certificate) directly into your Domino key file using the certsrv.nsf application. But SHA2 Domino certificates make that approach irrelevant.

With the advent of SHA2 for Domino and my misplaced belief (at least for LDAP, other protocols may work this way for all I know) that the cross certificate would allow the LDAPS connection to work I was actually looking in the wrong place.

This snippet from the original post was actually correct, but my actions were not:



It seems you still do need the AD root CA in your Domino key file, whether you need to actually cross-certify is debatable (for the record I left the cross-certificate in the Domino Directory). Doh on my part for not actually trying this out earlier. Now you can't do this with certsrv.nsf so I gambled on this and added the AD CA directly to the SHA2 Domino SSL key file. Here is how I did that:

1. Export your Windows CA root public certificate

2. Convert your CA public certificate into PEM format (either using OpenSSL or this site https://www.sslshopper.com/ssl-converter.html)

3. Using the krytool.exe application import  the PEM CA public certificate into your Domino SSL key file like this:

kyrtool ="e:\Program Files\IBM\Domino\notes.ini" import roots -i c:\ca_forWin.crt -k f:\Domino\data\keyring_sha2_wildcard.kyr

4. Ensure your new CA certificate is in the key ring:

kyrtool ="e:\Program Files\IBM\Domino\notes.ini" show roots -k f:\Domino\data\keyring_sha2_wildcard.kyr

which should give something like this:

Using keyring path 'f:\Domino\data\keyring_sha2_wildcard.kyr'

Trust Anchors:

Anchor 0 (name)

CN=blah-CA-PW-CA/DC=blah/DC=local

Anchor 0 (cert)

Subject:            CN=blah-CA-PW-CA/DC=blah/DC=local
Issuer:             CN=blah-CA-PW-CA/DC=blah/DC=local
Not Before:        04/13/2015 11:13:00 AM
Not After:        04/13/2035 11:23:00 AM
Key length:         2048 bits
Signature Alg:        sha256WithRSAEncryption

5. Add the new Domino key file to the server and voila, No more errors when Domino tries to make a TLS1.2 LDAPS connection to AD using SSL:

Here is the actual log on the server showing the connection, is indeed TLS1.2:

[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> Protocol Version = TLS1.2 (0x303)
[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> KeySize 256 bits
[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> Current Cipher = 0x009F (DHE_RSA_WITH_AES_256_GCM_SHA384)
[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> SSLErr = 0
[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> TLS/SSL Handshake completed successfully
[1178:000B-0F58] 07/15/2015 06:10:11.36 PM SSL_Handshake> Exit Status = 0

Here is the mea culpa, I was only testing with the LDAPSearch utility and it was only yesterday when the server change window kicked in (thanks Windows Update!...never thought I'd say that. Ever.) that I was able to test the earlier findings in production. But that failed. WTF? LDAPSearch works, Domino fails....that's what sent me back to the drawing board and actually figured out the root cause (no pun intended) was a missing certificate in the key ring file.

So lesson of the day, an error is an error but the error message is not necessarily the error message. And even though the product may get updates, don't necessarily think that the tools get updated as well. In fact, even after the solution I implemented LDAPSearch still fails even though DA using TLS1.2 actually does work.

DA working:



LDAPSearch breaking:

[0D70:0002-16CC] 07/15/2015 06:08:21.78 PM SSL_Handshake> Enter
[0D70:0002-16CC] 07/15/2015 06:08:21.78 PM SSL_Handshake> Current Cipher 0x0000 (Unknown Cipher)
[0D70:0002-16CC] 07/15/2015 06:08:21.78 PM SSL_Handshake> outgoing ->protocolVersion: 0303
[0D70:0002-16CC] 07/15/2015 06:08:21.78 PM SSLEncodeClientHello> We offered SSL/TLS version TLS1.2 (0x0303)

... snip ...

[0D70:0002-16CC] 07/15/2015 06:08:21.80 PM S_Write> Switching Endpoint to sync
[0D70:0002-16CC] 07/15/2015 06:08:21.80 PM S_Write> Posting a nti_snd for 7 bytes
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM SSL_EncryptData> SSL not init exit
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM S_Write> Switching Endpoint to async
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM SSL_EncryptDataCleanup> SSL not init exit
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM S_Write> nti_done return 0 bytes rc = 9
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM S_Write> nti_done return 0 bytes rc = 9 Event = 0x100
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM SSL_Handshake> After handshake2 state 2
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM SSL_Handshake> SSL Error: -6989
[0D70:0002-16CC] 07/15/2015 06:08:21.81 PM int_MapSSLError> Mapping SSL error -6989 to 4165 [SSLConnectionClosedError ]


ldap_bind_s( dn=cn=fppw ldap,cn=users,dc=blah,dc=local, pw=password, method=128 ) failed, error
: Not an LDAP errno 7289


SSL invalid certificate, may need to cross-certify.

Something else that just occurred to me while writing this that someone maybe able to shed some light on, maybe the AD CA root cross-certificate in the Domino Directory only works when you have a Domino CA enabled. At some point I need to test the theory.....again I swear I read this somewhere.....*grumble*