ERR_SSL_VERSION_OR_CIPHER_MISMATCH when connection to Omada controller

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH when connection to Omada controller

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH when connection to Omada controller
ERR_SSL_VERSION_OR_CIPHER_MISMATCH when connection to Omada controller
2022-04-13 14:05:38
Model: OC200  
Hardware Version: V1
Firmware Version: 5.1.7

Hi,

 

Now I found that I am unable to connect to my Omada controller from any web browser from any computer because I have this error message: ERR_SSL_VERSION_OR_CIPHER_MISMATCH

According to my investigation, it seems that Omada web server does not support any of the browser-suggested TLS cipher protocols. Unfortunately becuase the standard HTTP protocol is redirecting me to HTTPS, therefore I cannot connect to my Omada controller anymore.

 

Has anybody already have the same issue like me?

 

Here is a snippet from my wireshark communication:

This what my computer sends to the controller to build-up the TLS 1.2 session:

Frame 599: 571 bytes on wire (4568 bits), 571 bytes captured (4568 bits) on interface \Device\NPF_{3D190CA5-7456-49A4-A022-C6AFA9EB266B}, id 0
Ethernet II, Src: IntelCor_74:95:4b (ac:74:b1:74:95:4b), Dst: Tp-LinkT_1c:3f:22 (50:d4:f7:1c:3f:22)
Internet Protocol Version 4, Src: 192.168.10.178, Dst: 192.168.10.3
Transmission Control Protocol, Src Port: 50211, Dst Port: 443, Seq: 1, Ack: 1, Len: 517
Transport Layer Security
    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 512
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 508
            Version: TLS 1.2 (0x0303)
            Random: 1d5e5421e1ed36749e0f853e8c4d08b474398392fc0607cbcacdea1178064b72
            Session ID Length: 32
            Session ID: 983cdf1a7b2be141c2b19840d5a14349920881451e99180dc14404e20d095cc4
            Cipher Suites Length: 32
            Cipher Suites (16 suites)
                Cipher Suite: Reserved (GREASE) (0xeaea)
                Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
                Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
                Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
                Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 403
            Extension: Reserved (GREASE) (len=0)
            Extension: server_name (len=24)
            Extension: extended_master_secret (len=0)
            Extension: renegotiation_info (len=1)
            Extension: supported_groups (len=10)
            Extension: ec_point_formats (len=2)
            Extension: session_ticket (len=0)
            Extension: application_layer_protocol_negotiation (len=14)
            Extension: status_request (len=5)
            Extension: signature_algorithms (len=20)
            Extension: signed_certificate_timestamp (len=0)
            Extension: key_share (len=43)
            Extension: psk_key_exchange_modes (len=2)
            Extension: supported_versions (len=7)
            Extension: compress_certificate (len=3)
            Extension: application_settings (len=5)
            Extension: Reserved (GREASE) (len=1)
            Extension: padding (len=194)
            [JA3 Fullstring: 771,60138-4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,23130-0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513-64250-21,47802-29-23-24,0]
            [JA3: 6e16fe3b41d1f9893383e137372b18b5]

 

 

And here is the answer from  controller:

Frame 2757: 61 bytes on wire (488 bits), 61 bytes captured (488 bits) on interface \Device\NPF_{3D190CA5-7456-49A4-A022-C6AFA9EB266B}, id 0
Ethernet II, Src: Tp-LinkT_1c:3f:22 (50:d4:f7:1c:3f:22), Dst: IntelCor_74:95:4b (ac:74:b1:74:95:4b)
Internet Protocol Version 4, Src: 192.168.10.3, Dst: 192.168.10.178
Transmission Control Protocol, Src Port: 443, Dst Port: 50232, Seq: 1, Ack: 518, Len: 7
Transport Layer Security
    TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
        Content Type: Alert (21)
        Version: TLS 1.2 (0x0303)
        Length: 2
        Alert Message
            Level: Fatal (2)
            Description: Handshake Failure (40)

 

 

Any idea from anybody how I can get back the control of my omada controller? To be honest, I do not want to completely reset it.

 

Thanks!

Gabor

  0      
  0      
#1
Options
6 Reply
Re:ERR_SSL_VERSION_OR_CIPHER_MISMATCH when connection to Omada controller
2022-04-14 06:29:26

Hi  @vgaga84 

 

We have an user shared the solution for this issue. Please refer to: 

https://community.tp-link.com/en/business/forum/topic/219220

Happy New Year! Meet Us at CES 2023 | Featuring Wi-Fi 7, Omada Business Networking, VIGI Video Surveillance
  0  
  0  
#2
Options
Re:ERR_SSL_VERSION_OR_CIPHER_MISMATCH when connection to Omada controller
2022-04-14 06:35:24
Hi, Yes. I found this topic. But it I cannot acces to the OC200 keystore. The Omada is not running on a computer, so this solution is not usable for me. Thanks Gabor
  0  
  0  
#3
Options
Re:ERR_SSL_VERSION_OR_CIPHER_MISMATCH when connection to Omada controller
2022-04-14 09:38:47

So, I performend the following steps:

  1. Resetted OC200 to factory settings. When the factory reset finished, I could connect to the portal using HTTPS and with internal certificate.
  2. I reconfigured everything. Everything was working fine with its own original certificate using modern encryption settings.
  3. I uploaded my PFX certificate file (PFX format could not be a problem becuase I was using it in 2 versions earlier for long time without any problem). After the restart, I immediately received the same error message: ERR_SSL_VERSION_OR_CIPHER_MISMATCH

 

I don't know if my certificate could be wrong (I do not think because the previous certificate was working for a long time). However, it seems there could be some firmware issue when a new custom certificate is uploaded, the HTTPS configuration is not working properly.

 

The biggest problem is that I cannot connect to the OC200 using any file share or something. Therefore, I cannot remove the bad certificate. SSH is not working for me at all to the device even if I turn it on.

  0  
  0  
#4
Options
Re:ERR_SSL_VERSION_OR_CIPHER_MISMATCH when connection to Omada controller
2022-04-15 09:34:08

Hi  @vgaga84 

 

Are you still able to login the controller via cloud website? https://omada.tplinkcloud.com/

 

Have you done anything like firmware updating on the controller? What is the controller version right now? 

 

Your feenback will help us detect the issue. Thanks again for your cooperation. 

Happy New Year! Meet Us at CES 2023 | Featuring Wi-Fi 7, Omada Business Networking, VIGI Video Surveillance
  0  
  0  
#5
Options
Re:ERR_SSL_VERSION_OR_CIPHER_MISMATCH when connection to Omada controller
2022-04-15 11:08:36

 Hi @Hank21 

 

I found the root cause of the problem.

The issue is caused by that the controller is not checking if the uploaded PFX certificate is valid or not. It is applying the certificate even if some part if is invalid.

 

The validation is working fine if I want to upload a PEM+KEY pair as a certificate. In this case the controller informs me that my certificate is invalid and cannot be used. However, if I upload a PFX certificate, in this case it is not extracting using the password and does not test if the certificate is fine.

 

In my case the problem was that the private key in the the certificate was created by EC256 algorithm (elliptic curve 256bit) which is not supported by the controller. If I wanted to upload this certificate as PEM+KEY files, it notified me that the private key is invalid and cannot be used. This validation is missing in case of PFX certificate. However, after the restart the controller applied the invalid certificate, and the web server cannot be used anymore because the encryption could not be properly created due to the invalid certificate.

I resetted the controller again and created a new certificate with RSA256 (instead of EC265) private key algorithm, and after the upload it is already working fine.

 

To be honest I do not understand why it is not implemented some either a certificate validation during the saving process, or some fallback option if the certificate is invalid and cannot be used to avoid such situations in the future.

 

Thanks!

Gabor

  2  
  2  
#6
Options
Re:ERR_SSL_VERSION_OR_CIPHER_MISMATCH when connection to Omada controller
2022-04-19 07:45:25

Hi @vgaga84 

vgaga84 wrote

 Hi @Hank21 

 

I found the root cause of the problem.

The issue is caused by that the controller is not checking if the uploaded PFX certificate is valid or not. It is applying the certificate even if some part if is invalid.

 

The validation is working fine if I want to upload a PEM+KEY pair as a certificate. In this case the controller informs me that my certificate is invalid and cannot be used. However, if I upload a PFX certificate, in this case it is not extracting using the password and does not test if the certificate is fine.

 

In my case the problem was that the private key in the the certificate was created by EC256 algorithm (elliptic curve 256bit) which is not supported by the controller. If I wanted to upload this certificate as PEM+KEY files, it notified me that the private key is invalid and cannot be used. This validation is missing in case of PFX certificate. However, after the restart the controller applied the invalid certificate, and the web server cannot be used anymore because the encryption could not be properly created due to the invalid certificate.

I resetted the controller again and created a new certificate with RSA256 (instead of EC265) private key algorithm, and after the upload it is already working fine.

 

To be honest I do not understand why it is not implemented some either a certificate validation during the saving process, or some fallback option if the certificate is invalid and cannot be used to avoid such situations in the future.

 

Thanks!

Gabor

To figure out the issue, I'd like to escalate your case to the TP-Link support team for further troubleshooting.

They will reach you via your registered email address shortly, please pay attention to your email box later.

Once the issue is addressed or resolved, I'd encourage you to share it with the community.

Thank you so much for your cooperation and support!

Happy New Year! Meet Us at CES 2023 | Featuring Wi-Fi 7, Omada Business Networking, VIGI Video Surveillance
  0  
  0  
#7
Options