Certificate relies on legacy Common Name field, use SANs instead

[Raider (Will Raider)]

Hello everyone,

I wanted to use caddy as a reverse proxy for my services. When I reverseproxy to the unencrypted http:// variant of the services, it seems fine.
However I want to use the encrypted https:// variants also “behind” the proxy.

But, when I do that i get the following errors in the logs:

tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead

and for another service:

tls: failed to verify certificate: x509: cannot validate certificate for <IP> because it doesn't contain any IP SANs

Can I set an option in the caddyfile to ignore that and just connect to the service?

Version: v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=
Caddyfile:

{
	# General Options
	http_port 80
	https_port 443
	admin off

	# TLS Options
	email foo@bar.org

}


foo.my.domain {
	reverse_proxy https://hoastname.foo:443
}

bar.my.domain {
	reverse_proxy https://hostname.bar:443
}

test.my.domain{
	reverse_proxy https://IP:1234
}

[Raider (Will Raider)]

Ok answering my question:

You can use the tls_insecure_skip_verify option as stated in the Docs.

Weird that it is under http and not https.

Also …

Reverse proxy to an HTTPS upstream, but ⚠️ disable TLS verification. this is NOT RECOMMENDED, since it disables all security checks that HTTPS offers; proxying over HTTP in private networks is preferred if possible, because it avoids the false sense of security.

Does the clear traffic over http offer another advantages? Like: Is it faster without TLS?

[matt (Matt Holt)]

@Raider

tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead

This means the certificate presented by the backend only has a CommonName field, but this has been deprecated for about 20 years and Go no longer supports it. The backend app must present a modern, trustable certificate.

@Raider

tls: failed to verify certificate: x509: cannot validate certificate for <IP> because it doesn't contain any IP SANs

To make a secure connection to an IP address, you need an IP certificate, meaning a cert with an IP address instead of a domain name. Apparently that certificate does not have any IPs in it.

@Raider

You can use the tls_insecure_skip_verify option as stated in the Docs.

Beware that this disables all security, to the point where TLS is basically ignored, and you might as well not be using TLS at all.

@Raider

Does the clear traffic over http offer another advantages? Like: Is it faster without TLS?

Technically yes, and you might as well use HTTP as long as you trust the network between Caddy and the backend. If you don’t, then using TLS but disabling TLS verification is almost worse.

[Raider (Will Raider)]

@matt

but this has been deprecated for about 20 years

The NextCloud container from linuxserver.io uses such certificate apparently. lol.

@matt

To make a secure connection to an IP address, you need an IP certificate, meaning a cert with an IP address instead of a domain name. Apparently that certificate does not have any IPs in it.

Wouldn’t even be possible for private IPs, would it?

@matt

and you might as well use HTTP as long as you trust the network between Caddy and the backend. If you don’t, then using TLS but disabling TLS verification is almost worse.

I do trust the backend. But let’s pretend I do not: Wouldn’t some degree of encryption be better than none at all? (I imagine a script-kiddie in my network, that does know how to use wireshark, but does not know how to do man in the mittle attacks on TLS.)
I guess that is debateable.

[matt (Matt Holt)]

@Raider

Wouldn’t even be possible for private IPs, would it?

Yeah, you can issue your own IP cert just like any other cert. The problem is that if you’re issuing it yourself, you have to install the (root) cert into trust stores of clients like Caddy.

@Raider

I do trust the backend.

But what about the network in between? With TLS, you always need to trust the other end. But it’s the network it saves you from.

@Raider

But let’s pretend I do not: Wouldn’t some degree of encryption be better than none at all?

No, because, to quote another industry expert, you could be encrypting a connection with Satan.

Ultimately it depends on your threat model but in general if you disable TLS security, most models don’t reasonably gain any benefits of having the encryption either.

[francislavoie]

@Raider

You can use the tls_insecure_skip_verify option as stated in the Docs.

Weird that it is under http and not https.

The http there is the module name for the transport. The http module handles both HTTP and HTTPS traffic. Other transports include fastcgi which is a totally different protocol for sending the request to another server.

@matt

No, because, to quote another industry expert, you could be encrypting a connection with Satan.

Ultimately it depends on your threat model but in general if you disable TLS security, most models don’t reasonably gain any benefits of having the encryption either.

To clarify this further – if you ignore trust errors for TLS, the problem is that a man-in-the-middle can intercept the connection, decrypt the server’s response (as if it was the original client) manipulate/steal/change the response, then re-encrypt it using its own fake certificate, then send that back to the client.

In other words, there’s literally no security at all here, because this is the same “vulnerability” that exists if you used HTTP, i.e. a man in the middle could sniff/read/manipulate the traffic.

So might as well just use HTTP, because it has less overhead.