FR: support using self-signed IP-only certificate in custom DERP server, fingerprints for self-signed cert validation

What are you trying to do?

Not everyone has a domain name plus dns hosting. It's more accessible for users if we support using self-signed ip-only certificate in custom DERP server (just like k8s 6443 tls).

This issue had been brought up by #3647 and partially in #4082.

This feature is kind of implemented by a fork, ip_derper (which is regularly updated and just adding the patch for ip-based certificates):

https://github.com/yangchuansheng/ip_derper/blob/936de2789923d81b9eab538b50f124110dee6f9b/.github/workflows/main.yml#L21-L24

      - name: modify
        run: |
          cd tailscale
          sed -i '/hi.ServerName != m.hostname/,+2d' cmd/derper/cert.go

The above modification is not ideal for users who want to use domain-based tls certificates. I think some more appropriate minor fix could be the following:

tailscale/cmd/derper/cert.go

Lines 90 to 93 in 226486e

    
           func (m *manualCertManager) getCertificate(hi *tls.ClientHelloInfo) (*tls.Certificate, error) { 
        
           	if hi.ServerName != m.hostname { 
        
           		return nil, fmt.Errorf("cert mismatch with hostname: %q", hi.ServerName) 
        
           	}

 func (m *manualCertManager) getCertificate(hi *tls.ClientHelloInfo) (*tls.Certificate, error) {
-       if hi.ServerName != m.hostname {
+       if hi.ServerName != m.hostname && !(hi.ServerName == "" && net.ParseIP(m.hostname) != nil) {
                return nil, fmt.Errorf("cert mismatch with hostname: %q", hi.ServerName)
        }

So we could support well both domain-based certificates and the ip-based ones.

How should we solve this?

No response

What is the impact of not solving this?

Separate fork keeps patching this feature and some users fallback to that.

Anything else?

No response

Sorry, but this isn't a use case we want to support.

You're welcome to modify the Tailscale client or derper code for your own use.

Could you elaborate a bit more? As this feature is regularly brought up by other users.

If the official reponse to this feature is "make your own fork", then related issues in the future could get linked to the explanation.

People running their own DERP servers is a constant source of support costs for us. We provide the source code for transparency reasons and in theory it saves us money if people run their own, and it's better for users if their DERP servers are lower latency and close to them. So we do, and it's open source, and we support custom DERP servers.

And yet: so many people run them in bizarre unsupported ways and come to us for help, which we spend lots of time helping with.

We do not want yet another possible configuration to support and maintain in the code base, especially for something so fringe: LetsEncrypt is free, and domain names are often nearly free. So I'm skeptical there's enough demand for this feature to justify the various costs.

LetsEncrypt is free, and domain names are often nearly free. So I'm skeptical there's enough demand for this feature to justify the various costs.

In some countries, domains without an ICP license are not permitted to provide web services. For individual users, obtaining an ICP license can be extremely cumbersome.

https://en.wikipedia.org/wiki/ICP_license

For these users, supporting deployment of self-signed certificates based on IP would be extremely convenient.

so many people run them in bizarre unsupported ways and come to us for help, which we spend lots of time helping with.

I believe this only reflects the true demands of the community.

So I'm skeptical there's enough demand for this feature to justify the various costs.

I'm sorry, but you are contradicting yourself by pointing out that too many people are seeking support on one hand, while stating that this is a rare need on the other.

Domain names expose information that an IP does not.

The free certificate is only available for 3 months now, so it is very inconvenient to use certificates issued by institutions because they are only for encryption and not for other purposes. Why can't we use certificates made by ourselves?

Change in plans. We had a discussion and decided we'll do this.

We'll let you specify an optional TLS cert fingerprint in your DERP map on a node and use that, if present, to verify nodes instead of the normal WebPKI roots. And then, yes, if you set your hostname to an IP address, we'll let you skip SNI too.

tailscale,v2: remove ACLDERPNode.InsecureForTests

cmd/derper, derp/derphttp: support, generate self-signed IP address c…

I saw this feature has been released with the latest 1.82.0:

DERP functionality within the client supports certificate pinning for self-signed IP address certificates for those unable to use Let's Encrypt or WebPKI certificates.

However, tailscale status told me:

Tailscale could not connect to the 'xxx' relay server. Your Internet connection might be down, or the server might be temporarily unavailable.

At the same time, tailscale debug derp xxx told me:

"Error upgrading connection to node \"x.x.x.x\" @ \"x.x.x.x:44443\" to TLS over IPv4: tls: failed to verify certificate: x509: certificate is not valid for any names, but wanted to match sha256-raw:xxxxxxxxxxxxxxxxxxxxxx"

Anyone have tried this new feature?

I saw this feature has been released with the latest 1.82.0:

DERP functionality within the client supports certificate pinning for self-signed IP address certificates for those unable to use Let's Encrypt or WebPKI certificates.

However, tailscale status told me:
Tailscale could not connect to the 'xxx' relay server. Your Internet connection might be down, or the server might be temporarily unavailable.
At the same time, tailscale debug derp xxx told me:
"Error upgrading connection to node \"x.x.x.x\" @ \"x.x.x.x:44443\" to TLS over IPv4: tls: failed to verify certificate: x509: certificate is not valid for any names, but wanted to match sha256-raw:xxxxxxxxxxxxxxxxxxxxxx"
Anyone have tried this new feature?

I'm encountering this problem on Tailscale version 1.84.0. It works correctly on some of my devices but fails on others.
On devices that can connect to the DERP server successfully, running tailscale debug derp xxx outputs:

"Error upgrading connection to node \"x.x.x.x\" @ \"x.x.x.x:xxx\" to TLS over IPv4: tls: failed to verify certificate: x509: certificate signed by unknown authority"

On devices that cannot connect to the DERP server, running tailscale debug derp xxx outputs:

"Error upgrading connection to node \"x.x.x.x\" @ \"x.x.x.x:xxx\" to TLS over IPv4: tls: failed to verify certificate: x509: certificate is not valid for any names, but wanted to match sha256-raw:xxxxxxxxxx"

Additionally, on the devices failing to connect to the DERP server, running tailscale status outputs:

Tailscale could not connect to the relay server with ID 'xxx'. Your Internet connection might be down, or the server might be temporarily unavailable.

I'm unsure how to resolve this issue. Please let me know if you need any additional information to help diagnose the problem.

@XuRainbow

@XuRainbow This is fixed in #16016. Not released yet

Also see #15579

cmd/derper, derp/derphttp: support, generate self-signed IP address c…

cmd/derper: allow absent SNI when using manual certs and IP literal f…

cmd/derper, derp/derphttp: support, generate self-signed IP address c…

Hi! Any news on releasing the self-cert version of Tailscale app?

It runs properly on the latest version.

Hi! Any news on releasing the self-cert version of Tailscale app?

It runs properly on the latest version.

How? It still doesn't work, because I need to add my domain in the custom address field for Headscale. When I try to connect, I get error message that the connection was refused, and that the context got canceled.

I take it that this is because Tailscale app does not know that I run self-signed certificate, so it refuses my login. Have this function been tested properly?

I see an "auth key" section too, but this is something that needs to be generated by my console, and the preauth-key I generate from console doesn't get accepted by this section on the Tailscale app, it seems to be the wrong format.
I also think that it refuses it because still it doesn't trust my certificate.

Why Headscale? You should use Tailscale Derper.

This issue is only about DERP servers, not the control plane.

Navigation Menu

Repository navigation

FR: support using self-signed IP-only certificate in custom DERP server, fingerprints for self-signed cert validation #11776

What are you trying to do?

How should we solve this?

What is the impact of not solving this?

Anything else?

18 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	func (m manualCertManager) getCertificate(hi tls.ClientHelloInfo) (*tls.Certificate, error) {
	if hi.ServerName != m.hostname {
	return nil, fmt.Errorf("cert mismatch with hostname: %q", hi.ServerName)
	}

FR: support using self-signed IP-only certificate in custom DERP server, fingerprints for self-signed cert validation #11776

Description

What are you trying to do?

How should we solve this?

What is the impact of not solving this?

Anything else?

Activity

bradfitz commented on May 17, 2024

networkhermit commented on May 17, 2024

bradfitz commented on May 17, 2024

itsalongstory commented on Jun 13, 2024

ArcticLampyrid commented on Aug 7, 2024

NathanSweet commented on Nov 17, 2024

yafengabc commented on Dec 5, 2024

bradfitz commented on Dec 5, 2024

18 remaining items

jsbyysheng commented on Mar 27, 2025

XuRainbow commented on May 28, 2025

pelikanade commented on May 28, 2025

jsbyysheng commented on Oct 22, 2025

jsbyysheng commented on Nov 9, 2025

bradfitz commented on Nov 10, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions