TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Internal Error)

edit

As is often the case, troubleshooting by screenshot of a a few columns from a capture is a frustrating exercise. Can you please provide the capture?

If not, who is providing the Fatal alert, client or server? If the client I suspect there's something it doesn't like about the server certificate.

Sorry, yes we tried to sanitize with TraceWrangler but the output file becomes useless after sanitizing.

The fatal alert is from the Client and we were capturing on the server side. Wildcard certificate from GoDaddy is being used.

I think you'll have to debug the client, is it a browser? If so have you tried another? Can you use openssl s_client ... to make a debuggable connection?

no, the client is a teradici zero trying to establish a connection to it's management console over 5172.

if we try to access the url in ANY browser, we aren't able to reproduce the fatal alert. Chrome browser offers 17 cipher suites and agrees to use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) sent in the server Hello

http://www.teradici.com/web-help/TER1...

Looks like an issue in the client then.

Thanks for the openssl tip.

openssl s_client -connect my.domain.com:5172 -tls1_2 -showcerts
CONNECTED(00000003)
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = *.domain.com
verify return:1

Now I am wondering if it's an Nginx misconfigurataion or as you said the problem with the zero not sending the Client Key Exchange, Change Cipher Spec Encrypted Handshake in the next expected packet for some reason?

https://stackoverflow.com/questions/3...

Personally I still suspect the client, as everything else is happy with the server config and the client sends the alert immediately after getting the cert.

The client was breaking because the certificates were incorrectly placed in the crt file. The Root cert was inserted before the intermediary, when it should have been the last.

Interesting result, RFC 5246 (for TLS 1.2 which you seem to be using) says this about the list of certificates:

certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

So it appears that the Zero client was the only one that actually required the certs in the order specified in the RFC. From the RFC it appears that the root certificate can be omitted from the list rendering the order mute.