;       By default, TLSv1.0, TLSv1.1, TLSv1.2 protocols are enabled.
;       SSLv2 and SSLv3 protocols are disabled by default and cannot be enabled because they are weak ciphers.
;
;       Attributes to enable or disable TLS protocols are:
;       TLSv1.0 ----> SSLNOTLSv1 should be set to "true" or "false"
;       TLSv1.1 ----> SSLNOTLSv1_1 should be set to "true" or "false"
;       TLSv1.2 ----> SSLNOTLSv1_2 should be set to "true" or "false"
;
;       Example 1: To disable TLSv1.0
;                  SSLNOTLSv1 true
;
;       Example 2: To enable or disable multiple TLS versions, specify each value on a new line.
;                  SSLNOTLSv1 false    --- enables TLSv1.0
;                  SSLNOTLSv1_1 true   --- disables TLSv1.1
;                  SSLNOTLSv1_2 true   --- disables TLSv1.2
;
;   Note: If you modify the setting it will be necessary to restart NRM.

So where exactly do you set this?  I'm talking about iMonitor here, not NoRM.  So the httpstk in eDir/NDS (by default on port 8030).

Matt

Sorry for that, apparently i didn't read the post properly. As for imon: i'm not sure, but a quick test (on an OES box, though) showed that i had to edit the http-server object of the server in question and set

- httpKeyMaterialObject to an EC certificate

- httpBindRestrictions to 4, 5 or 6 (depending on the cert. I used 4)

After bouncing the daemon

openssl s_client -connect xx.xx.xx.xx:8030 -tls1and

openssl s_client -connect xx.xx.xx.xx:8030 -tls1_1

started failing while

openssl s_client -connect xx.xx.xx.xx:8030 -tls1_2

did still work.

Forgot to mention:

if you have the bindrestriction parameter set in nds.conf you'll have to set it there, too as it'll overrule the value on the http-server object.

Any other tips for this config? I tried using the default EC cert and I tried making my own cert, but I cannot seem to get iMonitor to work with an EC KMO and a bind restriction of 4, 5 or 6.  Never can get an SSL connection established.  If I got back to RSA and bind restrictions 3 it works.  

BTW, this is an awfully odd way of forcing TLS 1.2.  You can do TLS 1.2 with an RSA cert (I'm doing it with LDAP).  TLS has nothing to do with really which cert you use.  Is there some reason it's tied together like this?

Matt

I'd guess it's just tied to "Suite B" which expects 1.2 or better.

But just to clarify:

You can connect via TLS1, 1.1 and 1.2 via RSA with restriction type "3"?

And you can't connect with any of them via EC with type "4"?

Mathias Braun said:

You can connect via TLS1, 1.1 and 1.2 via RSA with restriction type "3"?

Correct.

Mathias Braun said:

And you can't connect with any of them via EC with type "4"?

Correct.

This keeps getting weirder.  I used an EC 256 cert with a bind restriction of 3. Now I can connect. TLS 1.0 is not allowed, but 1.1 and 1.2 are. 

I guess I'll keep testing different combinations.  Really dislike how this is implemented.

Matt

I created a new EC cert with a Key Size of 384 and a signature algorithm of SHA 256-EC. I assigned this to the http object and this time set the bind restrictions to 4. Now only TLS 1.2 is allowed.  Connect attempts using 1.0 and 1.1 fail. Not sure what is different (I did put the FQDN in the subject and I added the FQDN and short name to the SAN this time).

So it appears you CANNOT use an RSA cert and disable TLS 1.0 and 1.1 in iMonitor. I'm supposed to use certs minted from a corporate PKI infrastructure at this one site, but they only issue RSA certs.  So I keep getting dinged on security scans because iMonitor is allowing TLS 1.0 and 1.1.  I supposed they will either need to start issuing Elliptical Curve certs or have to accept that there is no way to disable TLS 1.0 and 1.1 in the httpstk if using an RSA cert.  Still think this is a screwy way to do this.  I don't know of any other app or platform that ties the TLS version to the type of cert.

Matt

I usually place both IP and FQDN as SAN. Even current GroupWise Code does corresponding checks.