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'
Anchor 0 (name)
Anchor 0 (cert)
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.
[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*
DA and AD's....how could this not get confusing?
Over the past few days I've been working to figure out why 9.0.1 FP4 can no longer connect to Active Directory when using a SSL connection for the LDAP connection from Domino. Specifically this is AD 2012 but I would guess the same issues hit 2012 R2. Not sure about 2008. Like this:
Anyway, what worked in 9.0.1 FP3 no longer worked after an upgrade to 9.0.1 FP4. After much testing it appears that Windows 2012 servers really doesn't like TLS1.2 when using Domino. A quick Google will show you than OpenSSL seems to have the same issue so it would seem this is a Windows Server issue as opposed to a Domino issue but that is pure speculation on my part.
Here's the testing I did to figure this out. I knew AD SSL was working thanks the LDP.exe tool on my PC. The connection to the domain controller over port 636 (the SSL) port came back fine.
On a server not running 9.0.1 FP3 (not FP4) I turned up SSL logging using these notes.ini settings:
I then fired up LDAPSearch.exe on the server, piped the query out to a text file and ran this query:
ldapsearch -h dc2-pw.blah.local -p 636 -D "cn=darren duke,cn=users,dc=blah,dc=local" -w password -b "dc=blah,dc=local" "objectClass=*"
On the working server (FP3) this was returned in the text file:
[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSLProcessServerHello> Server chose SSL/TLS version TLS1.0 (0x0301)
[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSLAdvanceHandshake> A certificate has been requested
[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSLAdvanceHandshake> An X509 certificate has been requested
[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSLAdvanceHandshake> Empty Server DN List
[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSLEncodeCertificate> Generating a certificate message with 0 certs
[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSL_Handshake> After handshake state= 13 Status= -5000
[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSL_Handshake> Exit Status = -5000
[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone]
[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSL_Handshake> Enter
[1BD44:0002-1C534] 07/13/2015 04:39:14.66 PM SSL_Handshake> Current Cipher 0x002F (RSA_WITH_AES_128_CBC_SHA)
OK so FP3 is using TLS1.0 and the RSA_WITH_AES_128_CBC_SHA (the 2F) cipher. Lets see what the same query from a FP4 server does:
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLEncodeClientHello> We offered SSL/TLS version TLS1.2 (0x0303)
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 0 Available cipherspec: 0x009F
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 1 Available cipherspec: 0x009E
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 2 Available cipherspec: 0x006B
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 3 Available cipherspec: 0x0039
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 4 Available cipherspec: 0x0067
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 5 Available cipherspec: 0x009D
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 6 Available cipherspec: 0x009C
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 7 Available cipherspec: 0x003D
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 8 Available cipherspec: 0x0035
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 9 Available cipherspec: 0x003C
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 10 Available cipherspec: 0x002F
[0824:0002-0C34] 07/15/2015 07:42:56.36 AM SSLInitContext> 11 Available cipherspec: 0x0033
... snip ....
[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSLSendAlert> Sending an alert of 0x0 (close_notify) level 0x2 (fatal)
[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Handshake> Changing SSL status from -6989 to -5000 to flush write queue
[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Handshake> After handshake state= 2 Status= -5000
[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Handshake> Exit Status = -5000
[0824:0002-0C34] 07/15/2015 07:42:56.38 AM int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone]
[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Handshake> Enter
[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Handshake> Current Cipher 0x0000 (Unknown Cipher)
[0824:0002-0C34] 07/15/2015 07:42:56.38 AM S_Write> Enter len = 7
[0824:0002-0C34] 07/15/2015 07:42:56.38 AM SSL_Xmt> 00000000: 15 03 03 00 02 02 00
.... snip ....
ldap_bind_s( dn=cn=darren duke,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.
Hum. So the 2F cipher is there but this is a TLS1.2 transaction. Also that last line threw me for a curve. Why would FP3 not care about a cross cert by FP4 does? I even added the root signing certificate from AD to Domino as an Internet Cross Certificate. No joy.
Next swing at this, I wondered if it was a TLS1.2 issue so I Googled the shit out of changing the ciphers in AD to test it. Argh, registry hacks,,,,more searching and I found this fantastic free tool to view/adjust Windows ciphers used by Schannel https://www.nartac.com/Products/IISCrypto/Download.
With this tool I adjusted the domain controller to the following (basically I selected "Best Practice, then disabled TLS1.1 and TLS1.2......oh, Domino does not like seeing TLS1.1 from the DC either):
Once I did that and rebooted the DC, voila, Domino 9.0.1 FP4 could now connect.
Again, I am not 100% certain here but this smells like a AD issue, but it is Domino that doesn't work. A Sonicwall VPN using LDAPS to the AD controller worked fine with TLS1.2, so maybe it is Domino. I did PMR this and after I'd already figured out my work around support suggested I add this to Domino server notes.ini:
So that is basically the same workaround but from the Domino side. This suggests one side or the other is either not handshaking correctly or cannot decide on a cipher when using TLS1.2.
It sure would be nice to have TLS1.2 everywhere. Some day perhaps. Someday.
While there have been some epic FUBAR's by IBM of late (renaming the Android Traveler app to Verse for example) this is a more basic problem. Installing their software. Now, I'm not talking about the all-by-uninstallable Websphere and Filenet stuff coming out of Lotus/ICS/ESS but something much simpler, IBM Mobile Connect (or Lotus Mobile Connect, or IMC).
Now this is not a necessarily a simple product to get working but the install was always pretty easy. Until I tried to install IBM 188.8.131.52 that is. And it's obvious not one single person tested this before it was launched.
So here goes. When I install IMC I get asked what I want the SQL databases to named (in this case I am using MS SQL Server, which may explain why IBM doesn't give a shit....ignore the by-far-largest-install-base-RDBMS-system is always a good move right?). I already have a working IMC so I'm going with a new SQL database, wgdatanew and wgacctnew:
Nothing too special there. A simple text box. Off goes the installer and the SQL databases do indeed get created. A few minutes later it is time to configure the Gatekeeper portion of IMC (basically the GUI client for the uninitiated). This is where the issue arises as soon as the wizard starts you hit this screen:
WTF? The installer seems to think my MS SQL database is named wgdatanewSQL. Where the hell did the appended "SQL" part of that name come from? Off we go to SQL Server to check:
Hum, no, the installer created the SQL databases like I wanted. (begin outrage) So how did this ever make it through QA and testing? How? The only plausible answer is that is wasn't tested. I can think of no other way to explain this.
I could PMR this, but really, do I need my question asked back to me in 4 different times in emails over 4 different days by 4 different "engineers"? No. I'll just fix it myself and let IBM be mis-led into thinking they create great software and have a great support arm.
Dear IBM, keep this up and you will lose customers (in fact we've seen one go because of Sametime meetings and it's complexity, so maybe that ship has already sailed).
Anyhow, I did come up with a work around. Simply rename the SQL Database and prepend the "SQL" to it, but do this before you close the Gatekeeper wizard as IMC gets really confused:
After that "fix" I'm able to finally install and use IMC. Not to harp on a point (OK, I'm harping on a point), but how can something this simple and this bad be let out into the world?
Richard has already mentioned he OGS IBM speakers, we've all seen Kramer (not to disrespect Kramer though), but the one of the two speakers I'm excited to see is Mr Phil Gilbert. He's the head of IBM Design (I know, IBM have design now....who'd have thought that a few years ago, right?). While I've never seen him present yet, everyone I know who has raves about it for days afterwards.
The other is Louis Richardson, and if his session is on the same time as mine, I may have to cancel my session and go to his. Seriously. I have a massive presenters crush on Louis (don't judge, I'm hoping SCOTUS will legalize this soon too), and while I do not know what his session is, I would literally go and watch Louis present on the advantages of IBM's certification program or on rules of cricket.....for those now wondering, start here https://en.wikipedia.org/wiki/Cricket (sorry I couldn't find reasonable links in the advantages of being certified).
In other possible, my happen, Magic 8 balls says "not in all likelihood", there may or may not be a This Week In Lotus recorded during the event. A whole lot of stars have to align for this to happen and I'm not sure I need the kind of anger and attack IBM like to level at people who differ in opinion to them. Still, it's not like that has ever stopped me in the past right? ;)
Finally, and I know I've said this before, but I'm still kicking about doing a "World According to Darren - part 2". I've got a few ideas and if I can string together enough irritating things it may make the light of day possibly on Friday of the MWLUG session week.
And finally, finally...no, really finally this time, this is your opportunity to come thank and buy a drink for none other than THE Susan Bulloch (she's actually presenting, so if you get a change go see her). There is a good chance that if you've ever had a C&S related PMR in the last *cough* number of years, then Susan most likely had a hand in getting it fixed.
So after all of that, what are you waiting for? Go register (places are going fast) over at the MWLUG site for the event that takes place on August 19th to the 21st at the Ritz-Carlton in Atlanta.
https://twitter.com/mashable/status/610722476193107968">June 16, 2015
I didn't give it much though. I use a password manager but it ain't the famous ones. I don't like the idea of someone else storing my list of God-like credentials. OK, I use two services like OneDrive and Google Drive but I'll get to why I don't have an issue with that until later....
I use the open source KeePass project.
What is KeePass?
Today you need to remember many passwords. You need a password for the Windows network logon, your e-mail account, your website's FTP password, online passwords (like website member account), etc. etc. etc. The list is endless. Also, you should use different passwords for each account. Because if you use only one password everywhere and someone gets this password you have a problem... A serious problem. The thief would have access to your e-mail account, website, etc. Unimaginable.
KeePass is a free open source password manager, which helps you to manage your passwords in a secure way. You can put all your passwords in one database, which is locked with one master key or a key file. So you only have to remember one single master password or select the key file to unlock the whole database. The databases are encrypted using the best and most secure encryption algorithms currently known (AES and Twofish). For more information, see the features page.
Is it really free?
Yes, KeePass is really free, and more than that: it is open source (OSI certified). You can have a look at its full source and check whether the encryption algorithms are implemented correctly.
What I like about KeePass is that I get to decide where my database file of password is stored. Said database is encrypted with 256 bit AES and mine is stored in a file sync service like Google Drive (as the KeyPass database is already encrypted with my chosen key I have no issues storing it in a file sync service). Additionally, KeePass allows two form factor to be enabled, so I also have my KeePass setup to require a key file that is required in addition to my password and that is shared with my PC's via another different file sync service (say MS One Drive). Yes I could keep in on some other form factor like a USB thumb drive, but that is a tad unwieldy for me. Anyway whenever I need to start KeePass or unlock it, I need both:
Other things I like is integration (via plugins, and there a lot of plugins) to Firefox and Chrome, personally for Firefox I use PassIFox (which also requires KeyPassHttp):
It also has a great password generator built right in:
Which will create a password like this example:
How guessable is that? Yeah, I know right....I also use the maximum number of characters a web site allows for passwords, so if a site is limited to 24 characters that's what I use. That alone is great for your security. For example using A-Z and a-z is 52 characters in total. A 24 character password is therefore 52^24. That's a big, big number (1111010^2 I think, but don't quote me on that), then add in numbers, special symbols and spaces (if the website allows it) and you have a pretty awesome password generated for you,
So what is the down side? Yeah, there's always a down side and that is mobile. Now there are iOS and Android implementations of KeePass and I use the iOS one on occasion but it's read only (you can't create password entries on the device) and it's not a simple matter to type (my admittedly complex) password on a small phone keyboard. Still it works but it's not too suave and sexy. Again I use the file sync iOS app to sync the KeePass database to the device.
So there you have it. If your looking for a pretty good (actually I'd say great) password manager and creation tool and you want complete control of your password database give KeePass a try. I love it (and it's probable that this was one of my TWiL tips back in the day, that's how long I've been using this).
Luckily a site has already been created to test your web servers, it is available at https://weakdh.org/sysadmin.html.
A quick test of a Domino 9.0.1 server with the latest FP & IF and the perfect forward secrecy server-side notes.ini settings enabled (see this previous blog post for those settings) you get this result:
Using my free Apache reverse proxy you'll get this (which is slightly better as Domino doesn't support ECDHE):
Either way, using the latest version of Domino with the right cipher list you should be OK. Again I ask.....when will Domino get ECDHE? I don't think this a "nice to have" any longer.
Anyway, even though it is technically called the Midwest User Group anyone can (and should) attend. So if you are in the Southeast you have no rational reason to not attend.
If you use any of the IBM collaboration technologies this a conference you should have on your schedule. "But Darren, I can't get $1,500 approved to attend a conference". That's fine. It's only $50. Yes Fifty. I didn't miss off a zero. So now what's your excuse? Unless they are sold out when you register you really don't have one (oh, and they do dell out, so register now). The conference is at the magnificent Ritz Carlton in downtown Atlanta and there is even a special hotel rate for MWLUG attendee so you even get this for a relative steal too.
If you read this far, you need to attend. Here's the link: http://www.mwlug.com/mwlug/mwlug2015.nsf/Home.xsp
(Oh, and hopefully Promnic will bring some of Catherine's cookies....that's reason enough to attend right there).
I had no subscriptions listed. None. Nada. Ziltch. WTF?
So I started adding in my subscriptions again and realized that when IBM rename a product (Lotus Domino becomes IBM Domino) then it drops off the subscription list. Blahhhh! Now, with any normal company this would be a once in a blue moon occurrence, but with IBM, like an old lady with a HSN addiction, they can't seem to refrain from buying into the hype and pulling the trigger.
Voila, list rebuilt:
So head on over the IBM my notifications site and add your subscriptions back in, then check it every 5 minutes or so because that seems to be the frequency of IBM product renames. (that last bit was a joke).
Now this fix is only for Domino 9.0.1 FP3, so now you have a further reason to upgrade to R9 (SHA2 wasn't enough?) and is provided as an IF from fix central. There are other goodies in this release too like additional ciphers and forward secrecy (aka FS). Forward secrecy? Yes...via Wikipedia:
In cryptography, forward secrecy (FS; also known as perfect forward secrecy, or PFS and also key erasure) is a property of key-agreement protocols ensuring that a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future.
However (there's always a however), IBM has chosen to not enable FS by default. This is due to IBM not knowing how crap your servers are, as FS is "resource intensive". If you have crap servers, like a Pentium II running your production environment then FS is not for you (neither is IT for that matter). If you running a pretty recent CPU and plenty of RAM, then you should be OK. And you really want FS.....no really, you do.
So you've decided that your server hardware is up to the task, what do you do to get FS and the promise of Angels singing and the cries of despair from hackers now thwarted? Well you have use Notes.ini settings. See IBM are doing good stuff here....they are giving us new, very important features in fix packs and IF's....the cost of that is there are not yet any UI equivalents in the server and config docs yet. I'm good with that, good on yer IBM.
A few blog posts back, I mentioned the SSLCipherSpec notes.ini setting and it is this setting that once again gets to do all the work. Here's the thing though.....I would change the values in this setting based on the use of the Domino server. I'm not convinced there is "one setting to rule them all yet". I would suggest to you, dear reader, that a Traveler server needs different settings to a iNotes server which is different to a SMTP gateway server. Before that go read Daniel Nashed's excellently detailed post on all the new ciphers then come back here.....
Remember, SSLCipherSpec will be used despite what you have in the server or internet document and it is server wide.
iNotes with XP and IE support
Let's start with iNotes. Some organizations still need XP with IE support. Yes they do. Get over it. This is a conniption free zone with regards to XP. If you do need XP with IE then use TLS 1.0 with Triple DES. Why? Well XP with IE does not support AES, so that cipher is out, RC4 is now frowned upon so that cipher is out, leaving us with 3DES. Given the use of XP with IE support and FS on other platforms, I would suggest this cipher list for an iNotes server and you'll get a A- on SSL Labs:
(Firefox and Chrome on XP do not have the same issues as IE)
iNotes without XP and IE support
Drop the 3DES cipher (0A), but SSLv3 still disabled, and get a A- on SSL Labs:
(will also work with XP running Firefox or Chrome)
Same as iNotes with no XP support:
SMTP Domino Gateway
This is where it gets tricky if you're using STARTTLS (you are using STARTTLS right?) or your iNotes server is also your SMTP gateway. I would love to be able to say kill off SSLv3 but that's only a decision you can make based on your findings of what breaks when others try to send you TLS messages, but I don't think there is one size fits all here. I would start with this and adjust as necessary (you may need to add RC4 ciphers back in):
or (with SSLv3)
or (with SSLv3 and RC4):
Domino LDAP for LDAPS Dir Sync
If you using any type of LDAP sync with cloud based services for things like Spam protection then this is difficult. You just need to try it and see.. For instance SpamHero (which I like a lot...) only uses SSLv2 (yes....T. W. O) last I checked. I did email them for clarification and they did say they are addressing this. I have not checked in a few weeks (Update July 29th 2015 - SpamHero now support TLS). So if this is the case, you cannot go above 9.0.1 FP2 for this server. Again, test. adjust, test again, repeat
You may be wondering about the "A-" on the SSL Labs test. Well, it's to do with older browser support for FS and IBM choosing to not (yet?) implement ECDHE ciphers. I hope at some they will reconsider this as this does seem to be the current trend in ciphers, and well, we don't want to be left a decade or more behind again, right? I wonder what the (now new) top ranked,, not fixed PMR is now?
So there you have it. TLS 1.2 support in Domino. Not quite as simple as you thought.
TLS/SSL support history of web browser - Wikipedia
Domino TLS Cipher Configuration - IBM
Domino SSL ciphers set in the Domino Server document are ONLY applicable to HTTP. Not SMTP, LDAP, et al.... Doh. You can set with note.ini— Darren Duke (@darrenduke) https://twitter.com/darrenduke/status/560186157930381312">January 27, 2015
Now, I'm back in the office it's time to address this. So based on that session it seems as if LDAP, SMTP, DIIOP, POP3 and IMAP (and Remote debug monitor?) protocols do not adhere to the cipher list in the server document (there was no mention of internet sites documents, but I would presume they are affected by this issue too). That means even if you indicate that the server should only use, say AES ciphers like this:
then any protocol that is not HTTP or HTTPS seems not to restrict this to AES. It would seem to allow RC4 and any other cipher allowed by the server (one would hope that with the TLS fix that also disabled low quality ciphers that none, 40 and 56 bit would get disabled by this but I can neither confirm nor deny this).
There is however a server notes.ini you can use that apparently does work on these errant protocols, but note, this also overrides anything in the server document FOR ALL PROTOCOLS so test first:
Use the NOTES.INI setting SSLCipherSpec to specify SSL restrictions for all protocols. Ciphers are specified by a 2-digit code. You can add as many ciphers as you need.
For example, to enable 3DES and RC4128SHA ciphers, enter the following line in the NOTES.INI file:
where 05 = 3DES and 0A = RC4128SHA.
So that's handy right? What about the two digit hex values? Well this is where you hit a bit of a brick wall. All I can find is this list:
(SSL users only) Determines which SSL-compliant cipher to use to encrypt files on the server. Specification numbers correspond to the following ciphers:
01 - SSL_RSA_WITH_NULL_MD5
02 - SSL_RSA_WITH_NULL_SHA
03 - SSL_RSA_EXPORT_WITH_RC4_40_MD5
04 - SSL_RSA_WITH_RC4_128_MD5
05 - SSL_RSA_WITH_RC4_128_SHA
06 - SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
09 - SSL_RSA_WITH_DES_CBC_SHA
0A - SSL_RSA_WITH_3DES_EDE_CBC_SHA
0B - SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
0C - SSL_DH_anon_WITH_RC4_128_MD5
0D - SSL_DH_anon_WITH_DES_CBC_SHA
To enter multiple ciphers, enter each cipher specification value, including leading zeros. Do not include spaces between values. For example:
SSLCipherSpec = 01020A
from http://www-10.lotus.com/ldd/dominowiki.nsf/dx/SSLCipherSpec. What you will no doubt notice is the absence of any AES ciphers in that list. My guess is a quick PMR (sic!) will get you all the values, but I can't seem to find them anywhere so I cracked open DDE and took a look:
So it looks to me as if AES 128 is "2F" and AES 256 is "35". I would still suggest you PMR this as you use any information on this blog at your own risk (see what I did there?).
So if you want to limit all protocols on a server to just RC4 128 SHA-1and MD5 and AES 128 and 256, which will give you a pretty good spread of clients then add this:
Again this will override anything in the server or internet sites documents. After sitting through Daniel and David's session there should be a lot more to come in the next few weeks, like TLS 1.2, new ciphers, SSLv2 handshake's (to prevent some issues people are having with STARTTLS between Domino and other servers) and other things I can no longer recall.