Is FallbackServerName still experimental?

[goksan]

What is your question?

Is FallbackServerName still experimental?

certmagic/config.go

Lines 76 to 81 in c61a4fe

	// FallbackServerName specifies a server name
	// to use when choosing a certificate if the
	// ClientHello's ServerName field doesn't match
	// any available certificate.
	// EXPERIMENTAL: Subject to change or removal.
	FallbackServerName string

Include any other information or discussion.

I want to serve a domain cert despite visiting via an IP address, like in this issue.

A proposed solution in that thread overrides the ServerName for known IP addresses and that works great, but in my case the IP(s) are unknown.

Simply removing the IP check from the proposed solution and unconditionally overriding the ServerName would cause TLS-ALPN challenges to fail.

What have you already tried?

I have 2 (seemingly) working solutions

Set FallbackServerName, it seems to work well for my use case, but it's listed as experimental.

Override ServerName only where SupportedProtos does not include acme-tls/1

tlsCfg := certm.TLSConfig()
getCrt := tlsCfg.GetCertificate
tlsCfg.GetCertificate = func(hello *tls.ClientHelloInfo) (*tls.Certificate, error) {
	acmeTLS := false
        for _, proto := range clientHello.SupportedProtos {
	        if proto == acmez.ACMETLS1Protocol {
		        acmeTLS = true
	        }
        }
        
        if !acmeTLS {
	        clientHello.ServerName = "domain.com"
        }
	return getCrt(hello)
}

[mholt]

Been a while, but IIRC, even without setting FallbackServerName or using the linked workaround, CertMagic should still at least be able to serve up IP certificates in response to a handshake without a ServerName.

but in my case the IP(s) are unknown.

Do you mean, that you can't tell the server to manage a certificate for an IP address, because you don't know the IP address?

If you don't know the domain names (or IPs, whatever the SANs are) before starting the server, you need On-Demand TLS (or you have to reload the config once you do know the server name / IP).

Most of CertMagic and TLS handshake stuff is the same whether it's IP or DNS, it's just the nuances of getting an IP certificate are more tricky than that of DNS names.

[goksan]

Ah it was a silly error on my part, I was inadvertently setting the ServerName to "" and breaking the acme-tls/1 challenge when I thought I was setting ServerName to the value of the discovered domain.

I don't need to use FallbackServerName or to check for acme-tls/1, I was unknowingly working around my error 😅

Problem solved!

If you don't know the domain names (or IPs, whatever the SANs are) before starting the server, you need On-Demand TLS (or you have to reload the config once you do know the server name / IP).

As a side note if you're interested - I wasn't aware of this at the time, I only came across it yesterday. I have been calling ManageSync with a single domain off the back of a HTML form submission to achieve something similar. I'm only provisioning a single cert for the user when they first install the application and prefer the UX of a longer form submission vs a longer initial handshake for this particular use case. Good to know it's there though if I need it in future.

[mholt]

Glad you figured it out then 👍