You can disable 1.0 and 1.1 as long as you leave 1.2 in place.

You mentioned the MA, though for completion’s sake, if we want to disable TLS 1.0 and 1.1 on the commserve, we first need to get SQL to a version and service pack that supports TLS 1.2. The following link will show you what needs to be installed for TLS 1.2 support for Microsoft SQL Server https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server Find the version of SQL you have and check the "Current Updates with TLS 1.2 Support" column. Query: select @@version to check current sql version and service pack. After this is done and up to date, then you can disable TLS 1.0 and 1.1 and Continue to use TLS 1.2 on commserve.

Thanks, Mike

How does one go about disabling TLS 1.0 and 1.1, after SQL has been upgraded?

Here’s a link I found:

To disable TLS1.0 and 1.1 https://docs.microsoft.com/en-us/skypeforbusiness/manage/topology/disable-tls-1.0-1.1 

It’s for Skype, though still applies.

Adding in this link as well which seems more applicable:

https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/disable-tls-1-1dot1-mbam-servers

I am still having issue with TLS 1.1 being open on port 443. Even after following the registry change instructions disabling TLS 1.1.

Nessus Scanner still sees 1.1/1.2 open. We need to have only 1.2 open.

Any other ideas?

i even tried adding this additional setting

Additional Settings Description (commvault.com)

Thanks, Mike. That’s above and beyond, I figured it was a Commvault-only change.

I have prepped the 2 reg files and I’ll import and test once an urgent restore is finished.

Very much appreciated

Hey Ricky!

if you followed the docs I sent earlier, open a support case and see if they can assist (share the case number here so I can follow accordingly). 

I’d also like to hear what Support has to say.

The customer insists that it’s Commvault that’s vulnerable (specifically post-11.25.9) and not the OS, so they refuse to apply any of the .reg fixes.

I’d like to give them some official statement to the contrary.

Agreed, @Shane .  You’re not the first person to raise this concern, so once you get that case created, share the incident number with me so I can follow up and ensure we can a very detailed answer which I’ll share here as well as in a KB article.

im opening a ticket with support now.

Thank you for suggestions.

Appreciate that, @Ricky .  Let me know the case number once you do.  I just reached out to their team leadership to ensure we get a full description on steps, etc.

Incident 211202-632

Thank you in advance.

Commvault got the issue resolved with the following instructions highlighted in yellow. Thanks

The service using port 443 should be tomcat. In order to remove tls 1.1 from being used there please we should try updating the server.xml file in <InstallationDirectory>\contentstore\apache\conf. Please check for protocols and confirm it reads as follows.

          <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="443" URIEncoding="UTF-8" maxPostSize="40960000" maxHttpHeaderSize="1024000" maxThreads="2500" enableLookups="false" SSLEnabled="true" scheme="https" secure="true" server="Commvault WebServer" compression="on" noCompressionUserAgents="gozilla,traviata" compressableMimeType="text/html,text/json,application/json,text/xml,text/plain,application/javascript,text/css,text/javascript,text/js" useSendfile="false" compressionMinSize="500"> 
      <SSLHostConfig certificateVerification="none" honorCipherOrder="true" protocols="TLSv1.2" ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"> 
        

If a change is made, please restart the tomcat service as well as IIS and then run another scan.

Glad to hear it!

@Shane , does this apply to your usage as well?

I’m not closing this one off until we have a comprehensive answer.

My issue is specifically on port 8403, this resolution wouldn’t apply, would it?

Opened case number 211203-69

Awesome, I’ll track that as well!

i believe it would, only reason i say that is due to the fact my Nessus scan checks that port for TLS 1.1 as well and it passed

Not in my case, the MAs with no Tomcat installed is vulnerable.

The case I opened is going in circles.

Let me see what I can do.

Edit: @Shane you have a Standard Contract (7am-7m M-F) so I can’t get it moved now, but if you call support Monday morning EST you can ask for a transfer to a US engineer.

Thanks Mike.

If it’s all the same with you I’d rather wait for your intervention on Monday, despite my references to this thread and proof that the relevant reg keys are in place, I get asked the same questions every time and you’re on the same wavelength, albeit several frequencies higher, as me.

Of course!  I’m on it now.

Thanks Mike.

I was given a hotfix and an Additional Setting which has solved the issue. Thank you so much for your help.

https://cloud.commvault.com/webconsole/browse/MyDrive.do?shareFolderId=754349&path=50b6aa65341f4f808c8e7602241556a3&iP=PUBLIC

Name: nForceTLSV12
Category: Session
Type: Integer
Value: 1

That’s great!

Appreciate you giving me the details as well.  Now this will be here for the next person 

Thanks for posting that, Shane. I meant to update this thread but hadn’t gotten the chance yet.

That hotfix will be incorporated into 11.25.12, for anyone else that sees this in the future. nForceTLSV12 won’t work until that hotfix is applied.