You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Navigating to https://172.16.128.56/ using Firefox returned a HTTP 421 which after some googling was caused by strict_sni_host being automatically enabled by client_auth.
And sure enought looking at the logs it seems that it doesn't match, in fact, there is nothing at all!
After disabling the strict_sni_host option by setting it to insecure_off I could access the page, but the client authentication was not working at all.
After much frustration, the only last thing was that I was using an IP and not a domain, so I temporarily set the host file of my machine so that server.vlan98.redacted.fr would point to 172.16.128.56. I also re-issued the server certificate with the domain to CN=server.vlan98.redacted.fr,OU=VLAN98,O=REDACTED and subjectAltName=IP:172.16.128.56, DNS:server.vlan98.redacted.fr
After editing the config and reloading, everything worked without any issue and Firefox prompted me for a client certificate.
This affects much more than TLS client authentication. The fact that strict_sni_host is off by default, hides the issue the real issue, which is that caddy does not consider an IP address as a valid ServerName for TLS
While this bug is very unlikely to appear for front-facing domains, it is entirely possible for local environments.
Thanks
The text was updated successfully, but these errors were encountered:
I think this might be the first time I've heard of trying to use client auth with an IP address. I'm not really sure if we can safely make this work for IP addresses.
There's no need to implement something unsafe, and we can both agree that it's a very unusual setup.
But in that case, a warning/error or at least documentation would be nice if someone tries to do something similar.
Even if you know that IPs are not valid ServerNames it's no obvious why client_auth is not working.
Hi,
So I wanted to try out TLS client authentication in a lab environment. This environment does not have a DNS server, so no domains.
I generated 3 certificates for my test:
CN=REDACTED-VLAN98 Certifiacte authority,OU=VLAN98,O=REDACTED
CN=172.16.128.56,OU=VLAN98,O=REDACTED
withextendedKeyUsage=serverAuth
andsubjectAltName=IP:172.16.128.56
CN=User1,OU=VLAN98,O=REDACTED
withextendedKeyUsage=clientAuth
And used this config
Navigating to
https://172.16.128.56/
using Firefox returned the default "Caddy works!" page and there was no SSL issues after importing the CA.I then moved on and added the
client_auth
directiveNavigating to
https://172.16.128.56/
using Firefox returned aHTTP 421
which after some googling was caused bystrict_sni_host
being automatically enabled byclient_auth
.And sure enought looking at the logs it seems that it doesn't match, in fact, there is nothing at all!
After disabling the
strict_sni_host
option by setting it toinsecure_off
I could access the page, but the client authentication was not working at all.After much frustration, the only last thing was that I was using an IP and not a domain, so I temporarily set the host file of my machine so that
server.vlan98.redacted.fr
would point to172.16.128.56
. I also re-issued the server certificate with the domain toCN=server.vlan98.redacted.fr,OU=VLAN98,O=REDACTED
andsubjectAltName=IP:172.16.128.56, DNS:server.vlan98.redacted.fr
After editing the config and reloading, everything worked without any issue and Firefox prompted me for a client certificate.
This affects much more than TLS client authentication. The fact that
strict_sni_host
is off by default, hides the issue the real issue, which is that caddy does not consider an IP address as a valid ServerName for TLSWhile this bug is very unlikely to appear for front-facing domains, it is entirely possible for local environments.
Thanks
The text was updated successfully, but these errors were encountered: