CRITICAL - Cannot make SSL connection

Help
1

We have a monitoring service that uses Icinga and currently we get the following error for a domain on our Caddy server.

State: CRITICAL

Date/Time: 2018-03-09 12:43:49 +0100

Additional Info: CRITICAL - Cannot make SSL connection.
47592018841120:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:770:

We compile Caddy from source and --version shows

Caddy 0.10.11 (+5552dcb Thu Mar 08 14:26:59 UTC 2018) (unofficial)
1 file changed, 36 insertions(+), 74 deletions(-)
caddy/caddymain/run.go

I believe the command used to test this is the following after talking to support

openssl s_client -connect domainname:443 -msg -prexit -debug

The only error I see when running this is

verify error:num=20:unable to get local issuer certificate

Is there a bug in Caddy causing this or is it something I can do on my end to fix this?

2

A tlsv1 alert? Caddy doesn’t support TLS 1.0 by default; you’ll have to enable that with the tls directive. But I don’t recommend it, instead use TLS 1.2 to make the connection.

3

Perfect, that makes more sense.

You are right, we don’t want to support it. I guess I dug in too deep into debugging that I didn’t see the most obvious problem :slight_smile:

4

@matt I did some further testing and noticed that I could isolate the error from the monitoring server inside the caddy log. This allowed me to reproduce the error with the openssl command. The error looks like this.

Mar 12 11:30:05 30 server caddy.linux.amd64[26748]:  2018/03/12 11:30:05 http: TLS handshake error from 84.46.xx.xxx:50265: hostname '' does not qualify for certificate
Mar 12 11:30:10 30 server caddy.linux.amd64[26748]:  2018/03/12 11:30:10 http: TLS handshake error from 84.46.xx.xxx:50292: hostname '' does not qualify for certificate

Now the weird thing is I am able to reproduce this error with tls1.2. Here is the full error that I receive during my test

<<< TLS 1.2 Alert [length 0002], fatal internal_error
    02 50
140736228856712:error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22/libressl/ssl/s3_pkt.c:1133:SSL alert number 80
140736228856712:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22/libressl/ssl/s3_pkt.c:522:

It does not occur every time, I use a simple bash script to test with

#!/bin/bash

while true; do
        echo | openssl s_client -connect domainname:443 -msg -prexit -debug -tls1_2
        date
        echo $?
        sleep 1
done
5

What’s your Caddyfile?

6

Here is the caddyfile, it contains about 30 domain entries following this format.

https://{{h.name}}  {
	gzip
	log / /var/log/caddy/access.log "{remote} - [{when}] {method} {path} {proto} {host} {status} {size}"
	tls {
 	   max_certs 10
	}

	header /  Strict-Transport-Security "max-age=31536000;"

	proxy / {{h.ip}}:{{h.port}} {
		transparent
	}
}
7

Does {{h.name}} expand to a non-empty string?

Might be irrelevant, but I wanted to check.

hostname ‘’ does not qualify for certificate

That message given you when you’re using s_client means that Caddy isn’t getting SNI information; in other words, your client isn’t using SNI when making the connection, and Caddy can’t get a certificate for an empty hostname.

8

Thanks for the help @matt I don’t see anything wrong in our Caddyfile. It’s a fairly long file, I could send it in a pm if it would help.

The weird thing is that we just recently starting receiving this error when we upgraded to 0.10.11. Everything had been working fine for the past year. The only changes we have made is to add more sites using the same format to our Caddyfile.

The good thing is that I don’t see any regular users throwing this error. I am a backend developer with some ops experience, I have never worked much with networking and ssl. I know very little about SNI so I will need to read up on it to understand the problem better.

9

We changed how empty SNI is handled in 0.10.11 (an improvement, in fact) – and regular users with browsers won’t see the errors; but your client will need to use SNI. Most do, and with s_client I think there’s a way to specify it.

10

Alright, that makes sense. Let’s hope that this is what caused the problem. The new command would be:

openssl s_client -servername domainname -connect domainname:443 -msg -prexit -debug -tls1_2

There was also a check via Nagios that uses their check_http function and I am assuming it wasn’t using SNI.

11

@matt do you know why my previous openssl s_client command would only fail sometimes and work most of the time?

12

I have a hunch, but unless I see the full and finished Caddyfile I can’t be sure. I can’t offer support privately for free, so you’ll have to post it here in the thread or try https://github.com/mholt/caddy/pull/2037 and see if that fixes it.

13

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.