SMA v11 upgrade broken TLS - only SSLv3 available

[Notes Administrator]

2 SMAs

1 negotiating TLS1.0, 1.1, 1.2 connections

1 not negotiating any TLS connections only SSLv3

XML file exactly the same for SSL config

SSLConfig CLI table showing N/A next to TLS1.1 and TLS1.2 for each service.

As opposed to showing N (as not configured) on the working SMA.

As a side issue - the working SMA is not configured with TLS1.1 and 1.2, yet connections are being negotiated to TLS1.2

Tried to enable TLS1.1 and TLS1.2 on working appliance - success

Copied the modified XML to broken SMA - not accepted 

Configuration file was not loaded. Parse Error on element "ssl_inbound_method" line number 6475 column 25 with value "tlsv1_0tlsv1_1tlsv1_2tlsv1_0tlsv1_1tlsv1_2": That value is not valid.

Any ideas?  Raised with TAC, hoping this isn't a rebuild. 

[Mathew Huynh]

Hello Notes Admin,

Which version 11 build was it? Also for which part are you seeing the issues on the SSL configuration, INBOUND/OUTBOUND/GUI ?

Thanks,
Matthew

[Notes Administrator · Accepted solution]

Note that one SMA upgrade was fine (secondary SMA), the other not (primary)

This affected ALL services using TLS
- email not routing to/from the SMA quarantines
- GUI not accessible
probably other services if they were not enabled for SSLv3 and the client
was able to use SSLv3.


The upgrade went from
v10.1.0-052 to v11.0.0-128 - this is where I believe the issue had already
occurred.
then to v11.0.0-132

The fix was a manual correction of the SSL configuration lines in the XML
config.
There are several - for each service.

From what I can see, something has updated the XML configuration so that
TLS v1 is presented as tlsv1_0 rather than tlsv1
This is also present on the Secondary SMA, however I could not copy and
apply the SSL config as it does not recognise the value.
So I should really now go and correct the Secondary XML - as it may be on
the next reboot or config update around SSL that makes the issue reappear
and break TLS.

As the XML was corrected for each service, you could see in the SSLconfig
CLI table that when editing Versions, the options for all SSLv3, TLSv1,
TLSv1.1, TLSv1.2 were becoming available to configure and the table had N
or Y rather than N/A.

Had to then delivernow on SMA + ESAs to clear those quarantine messages
held up, rather than wait for next attempt.
Saved having to failover and mess about with reconnecting the ESAs to the
secondary.

[Mathew Huynh]

Hey Notes Admin,

I'm sorry that you had to go through the trouble with the XML editing to get it to load.
It seems the syntax was indeed changed in the version 11 variants which rendered them as NA as you saw due to incorrect syntax essentially 'stopped' the service from functioning.

This would have been the -recommended- option for correction, XML editing rather than the entire process of rebuilding / fail over.

I'm glad to see you had corrected it - I marked this as the solution as when encountering the issue you saw - this is the only available means for corrective measure at this stage.

This applies to ESA/SMAs which the XML syntax was changed into the system and not being accepted when loaded into another/back in.

Regards,
Matthew

[Libin Varghese]

Hi,

You can try removing the lines in <ssl> section that has tlsv1_0tlsv1_1tlsv1_2tlsv1_0tlsv1_1tlsv1_2 and load the config.

 Regards,

Libin Varghese