How to configure a default self-signed certificate (managed by Caddy)?

borjapazr · December 10, 2024, 5:36pm

1. The problem I’m having:

Hello!

This is more of a question than a problem. I am aware that in order for Caddy Server to be able to automatically obtain a certificate for a domain or IP you need to explicitly specify the site address (the name) in the configuration. If it is not specified a site address, Caddy will not be able to obtain a certificate, neither using tls internal, unless on demand tls is used.

The question I have is simple, is it somehow possible for Caddy Server to generate a self-signed certificate to use by default in case configurations like the following are set?

:443 {
    responde "Hello world!"
}

With this configuration, invoking https://localhost, will result in an error saying that the TLS Handshake cannot be completed because a certificate cannot be obtained for that server name or IP.

What I am asking is if there is a possibility to configure a catch all certificate. I am aware that you can use the on demand TLS to do this, but I would like to know if Caddy Server can solve the use case I raise in a more straightforward way. Obviously, a custom certificate could be configured, but it would not be managed by Caddy Server.

Thank you in advance.

Regards!

2. Error messages and/or full log output:

N/A

3. Caddy version:

v2.8.4

4. How I installed and ran Caddy:

N/A

5. Links to relevant resources:

N/A

matt · December 12, 2024, 11:06pm

What is “more straightforward” than 2 lines of config, for something that no other web server can do? The solution is on-demand TLS, so, why is that not acceptable?

What kind of custom certificate can act as a catch-all? (You’d need to have an impractical amount of SANs.) And why can’t Caddy manage it?

borjapazr · December 13, 2024, 10:16am

Hello @matt ,

First of all, I want to emphasize one thing. I don’t want what I ask in this post to be seen as a criticism, it is simply a doubt that came up and I would like to solve .

I agree that the on-demand TLS configuration is very easy to configure and totally acceptable, and I find it a marvel, in fact.

If I was asking about the possibility of generating a self-signed certificate that acts as a catch-all certificate in case a site address is not specified, it is because sometimes it can be quite a useful feature. For example, if you specify an address such as :443, to catch all accesses to the server that do not correspond to a particular site address, and you want the server to return a certificate instead of an ERR_SSL_PROTOCOL_ERROR, you could configure a self-signed certificate to act as a catch-all. In this way, the client and server could successfully complete the request. Obviously it is not going to be a valid certificate with all SANs, but at least there would be a certificate that could be presented to the client. To give an example, Traefik does something similar to this and generates a default certificate that looks like this:

PS: I like Caddy more than Tarefik

Regards!

matt · December 13, 2024, 4:26pm

I’m going to be bluntly honest – this is terrible. A server should not knowingly provide an invalid certificate to a client as it requires the client to disable security in order to continue, defeating the purpose. It undermines the credibility and reliability of the WebPKI and conditions users to ignore warnings.

borjapazr · December 14, 2024, 12:50am

I know and I totally agree with you, @matt. I was simply asking about the feasibility of this in Caddy Server, but really, if one wanted to provide a catch all certificate it would be as simple as generating it manually and using the tls directive.

I can think of a case where it may become useful. For example, if we try to access by IP to a web service using https. It’s a rare and extreme case, I know. But it’s for thinking about the small details. For example, in the case of Google an invalid certificate is returned and, as soon as the client accepts the risk, it is redirected to google.com.

~ ❯ nslookup google.com
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
Name:	google.com
Address: 142.250.184.174

~ ❯ openssl s_client -showcerts -connect 142.250.184.174:443
Connecting to 142.250.184.174
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 OU=No SNI provided; please fix your client., CN=invalid2.invalid
verify error:num=18:self-signed certificate
verify return:1
depth=0 OU=No SNI provided; please fix your client., CN=invalid2.invalid
verify return:1
---
Certificate chain
 0 s:OU=No SNI provided; please fix your client., CN=invalid2.invalid
   i:OU=No SNI provided; please fix your client., CN=invalid2.invalid
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan  1 00:00:00 2015 GMT; NotAfter: Jan  1 00:00:00 2030 GMT
-----BEGIN CERTIFICATE-----
MIIDfDCCAmSgAwIBAgIJAJB2iRjpM5OgMA0GCSqGSIb3DQEBCwUAME4xMTAvBgNV
BAsMKE5vIFNOSSBwcm92aWRlZDsgcGxlYXNlIGZpeCB5b3VyIGNsaWVudC4xGTAX
BgNVBAMTEGludmFsaWQyLmludmFsaWQwHhcNMTUwMTAxMDAwMDAwWhcNMzAwMTAx
MDAwMDAwWjBOMTEwLwYDVQQLDChObyBTTkkgcHJvdmlkZWQ7IHBsZWFzZSBmaXgg
eW91ciBjbGllbnQuMRkwFwYDVQQDExBpbnZhbGlkMi5pbnZhbGlkMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzWJP5cMThJgMBeTvRKKl7N6ZcZAbKDVA
tNBNnRhIgSitXxCzKtt9rp2RHkLn76oZjdNO25EPp+QgMiWU/rkkB00Y18Oahw5f
i8s+K9dRv6i+gSOiv2jlIeW/S0hOswUUDH0JXFkEPKILzpl5ML7wdp5kt93vHxa7
HswOtAxEz2WtxMdezm/3CgO3sls20wl3W03iI+kCt7HyvhGy2aRPLhJfeABpQr0U
ku3q6mtomy2cgFawekN/X/aH8KknX799MPcuWutM2q88mtUEBsuZmy2nsjK9J7/y
hhCRDzOV/yY8c5+l/u/rWuwwkZ2lgzGp4xBBfhXdr6+m9kmwWCUm9QIDAQABo10w
WzAOBgNVHQ8BAf8EBAMCAqQwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC
MA8GA1UdEwEB/wQFMAMBAf8wGQYDVR0OBBIEELsPOJZvPr5PK0bQQWrUrLUwDQYJ
KoZIhvcNAQELBQADggEBALnZ4lRc9WHtafO4Y+0DWp4qgSdaGygzS/wtcRP+S2V+
HFOCeYDmeZ9qs0WpNlrtyeBKzBH8hOt9y8aUbZBw2M1F2Mi23Q+dhAEUfQCOKbIT
tunBuVfDTTbAHUuNl/eyr78v8Egi133z7zVgydVG1KA0AOSCB+B65glbpx+xMCpg
ZLux9THydwg3tPo/LfYbRCof+Mb8I3ZCY9O6FfZGjuxJn+0ux3SDora3NX/FmJ+i
kTCTsMtIFWhH3hoyYAamOOuITpPZHD7yP0lfbuncGDEqAQu2YWbYxRixfq2VSxgv
gWbFcmkgBLYpE8iDWT3Kdluo1+6PHaDaLg2SacOY6Go=
-----END CERTIFICATE-----
---
Server certificate
subject=OU=No SNI provided; please fix your client., CN=invalid2.invalid
issuer=OU=No SNI provided; please fix your client., CN=invalid2.invalid
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1386 bytes and written 382 bytes
Verification error: self-signed certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self-signed certificate)
---

~ ❯ curl -I -k https://142.250.184.174
HTTP/2 301
location: http://www.google.com/
content-type: text/html; charset=UTF-8
date: Sat, 14 Dec 2024 00:44:03 GMT
expires: Mon, 13 Jan 2025 00:44:03 GMT
cache-control: public, max-age=2592000
server: gws
content-length: 219
x-xss-protection: 0
x-frame-options: SAMEORIGIN
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

As I said, I’m not trying to convince anyone about whether this is a good idea or not. Obviously, having the possibility to use on-demand TLS, this may not make sense as you could end up with the same behavior or even a better one.

Regards.

system · January 13, 2025, 12:51am

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