Only on azure: Could not create SSL/TLS secure channel

前端 未结 2 2124
再見小時候
再見小時候 2021-02-14 16:56

I run an application on the Azure application Standard: 1 Small plan. Framework is 4.6.1

This application is calling a SSL secured API. The SSL is published by StartCom

2条回答
  •  既然无缘
    2021-02-14 16:59

    Capture the TLS handshake. If your ServerHello is missing you most probably don't have a common cipher suite with the remote.

    Run both through https://www.ssllabs.com/ssltest/ to check supported cipher suites at both ends. For Windows Server, cipher suites can only be enabled or disabled globally (as in no distinction between client/server component) so that's why this makes for a good test.

    UPDATE: Found a glaring problem in my reasoning, App Service has a frontend layer and that's where TLS terminates, so comparing ciphers that way goes nowhere.

    Instead, run

    Get-TlsCipherSuite
    

    from Kudu's PowerShell and compare ciphers against your remote API's (the ciphers of which you can check over at https://ssllabs.com/ssltest). You should have at least one match.

    If none match, you'll need to switch to Cloud Services or VMs and enable at least one of the cipher suites your remote speaks. Having to go this direction usually means one thing -- your remote is using weak cryptography (SSL 3.0 or TLS 1.0 with RC4) and you should have a chat with those citizens, or find new citizens that are rocking TLS 1.2.

    From your System.Net trace:

    [8356] 00000000 : 15 03 03 00 02
    

    That's byte sequence for Fatal Handshake Error, which builds on my no common cipher theory.

    Note the first byte (0x15):

     Record Type Values       dec      hex
     -------------------------------------
     CHANGE_CIPHER_SPEC        20     0x14
     ALERT                     21     0x15
     HANDSHAKE                 22     0x16
     APPLICATION_DATA          23     0x17
    

提交回复
热议问题