Underscores not allowed in "Alt hostname" configuration parameter

[aaronlehmann]

When the "Alt hostname" parameter is set to a name that includes an _, the Coder plugin is not able to connect. When attempting to connect, it fails with the error "Contains non-LDH ASCII characters", which appears to refer to the "Alt hostname" parameter. This means there is no way to configure the JetBrains plugin to connect to hosts that present a SAN that includes an _. This configuration doesn't present a problem for the VS Code extension.

[fioan89]

Thank you @aaronlehmann for posting this. Could you also attach the logs, I'm mostly interested if there is any stack trace related to the issue.

[aaronlehmann]

Hi @fioan89, here is the exception:

2025-09-16 08:45:58,224 [ 273454] SEVERE - CoderGatewayRecentWorkspaceConnectionsView - Contains non-LDH ASCII characters
java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
	at java.base/java.net.IDN.toASCIIInternal(IDN.java:314)
	at java.base/java.net.IDN.toASCII(IDN.java:138)
	at java.base/javax.net.ssl.SNIHostName.<init>(SNIHostName.java:100)
	at com.coder.gateway.util.AlternateNameSSLSocketFactory.customizeSocket(TLS.kt:179)
	at com.coder.gateway.util.AlternateNameSSLSocketFactory.createSocket(TLS.kt:173)
	at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.kt:369)
	at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.kt:337)
	at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:209)
	at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
	at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
	at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
	at okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.kt:221)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at com.coder.gateway.sdk.CoderRestClient$special$$inlined$-addInterceptor$3.intercept(OkHttpClient.kt:1089)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at com.coder.gateway.sdk.CoderRestClient$special$$inlined$-addInterceptor$2.intercept(OkHttpClient.kt:1080)
	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
	at okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
	at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
	at retrofit2.OkHttpCall.execute(OkHttpCall.java:207)
	at com.coder.gateway.sdk.CoderRestClient.me(CoderRestClient.kt:159)
	at com.coder.gateway.sdk.CoderRestClient.authenticate(CoderRestClient.kt:149)
	at com.coder.gateway.views.CoderGatewayRecentWorkspaceConnectionsView$fetchWorkspaces$2.invokeSuspend(CoderGatewayRecentWorkspaceConnectionsView.kt:401)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:100)
	at kotlinx.coroutines.internal.SoftLimitedDispatcher$Worker.run(SoftLimitedDispatcher.kt:130)
	at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:89)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:613)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:1183)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:778)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:765)

[fioan89]

Thank you @aaronlehmann. I've pushed a fix over at #579 which I could only test with UTs, though I'm confident it will work.

But if I may insist a bit on this issue, I believe the replacement for Gateway - i.e. Toolbox will have similar issues and I'm not entirely confident that skipping the validations for SNIs is the right approach long term. Which is why I'm trying to fully understand your workflow and maybe come up with an alternative approach.
I'm assuming (please correct me if I'm wrong) this is a case where you are trying to reach example.com:8090 for the sake of the argument. On your side, the server is looking at the TLS SNI parameters and tries to determine which certificate to respond back. If there is no altHostname then the SNI will be set to example.com. Is this train of thought correct? In which case I wonder if custom Dns resolver at the rest client level can solve the issue without having to rely on non compliant SNI names. Something like:

val client = OkHttpClient.Builder()
    .dns { hostname ->
        if (hostname == "example.com") {
            listOf(InetAddress.getByName("10.0.0.5")) // internal IP for example.com
        } else {
            Dns.SYSTEM.lookup(hostname)
        }
    }
    .build()

[aaronlehmann]

I'm assuming (please correct me if I'm wrong) this is a case where you are trying to reach example.com:8090 for the sake of the argument. On your side, the server is looking at the TLS SNI parameters and tries to determine which certificate to respond back. If there is no altHostname then the SNI will be set to example.com. Is this train of thought correct?

Not quite. The server always responds with the same cert, which has a SAN that doesn't match its DNS name, and the TLS handshake will fail if the client isn't configured to expect this SAN (using "Alt hostname").

We're trying to migrate to a different cert which very unfortunately includes a _ in its SAN, so it isn't currently possible to configure a matching value in "Alt hostname".

[fioan89]

Oh, I see. Just to clarify — does the server always return the same certificate regardless of the SNI provided in the ClientHello, or does it actually check the SNI and abort the handshake if the SNI isn’t supported?

The reason I’m asking is that in our codebase we currently have two layers of custom logic:

one that alters the SNI in the ClientHello (via a custom SSLSocketFactory), and

another that compares an alternate hostname against the SAN entries during client-side certificate verification.

This setup makes it seem like SNI is critical for the server (beyond just the typical use case of serving multiple hostnames from a single IP).

But the statement “The server always responds with the same cert, which has a SAN that doesn't match its DNS name, and the TLS handshake will fail if the client isn't configured to expect this SAN” suggests that the real issue is only on the certificate verification side.

If that’s the case, perhaps it would make sense to simplify things and move away from this brittle SNI-rewriting logic, and instead adopt something more standard, like certificate pinning. It will certainly improve/simplify the logic on the plugin side.

And by the way, thank you for taking the time to walk me through this. I wasn’t around when the custom logic was originally introduced, so I’m missing some of the background — which is why my questions might feel a bit repetitive. Even if we ultimately can’t simplify the plugin code, I still plan to document everything clearly once I have a full understanding of your requirements.

[aaronlehmann]

Just to clarify — does the server always return the same certificate regardless of the SNI provided in the ClientHello, or does it actually check the SNI and abort the handshake if the SNI isn’t supported?

Yes, the server always returns the same certificate and I don't believe it cares about the SNI in ClientHello. So any simplification that avoids messing with ClientHello would be welcome - I'd be happy to test this.

BTW, thanks so much for engaging on this issue. I realize it's a strange ask and do feel sort of bad asking for a fix on your end for something that's not standards-compliant on our side. In parallel I'm trying to figure out if there's anything I can do to work around this on my side (via a corrected certificate), and that's proving a little tricky, but I should know with more certainty in the next few days.

[fioan89]

Thank you. I'll release the existing fix today, which hopefully will unblock you. But then, with your help I propose we try two things:

• I'll remove the SNI augmentation in the TLS handshake. This first approach should confirm that only custom hostname verification is needed during certificate verification.
• if the first step is succesul I think we can try instead to do certificate pinning. The idea is that instead of doing custom certificate validation, we can configure the http client to just verify the certificate sha without bothering with SANs. It will change the UI experience, instead of providing an alt hostname, a check sum will have to be copied. We can make it even more flexible and allow you to configure hostname and checksums.

What do you think?

[aaronlehmann]

The first point sounds great to me. On the second, I don't think we can rely on the certificate checksum being stable in our particular case. It would actually be fine for us to completely disable hostname validation and trust anything signed by the CA - that's how we set up other TLS clients internally.

[aaronlehmann]

Thanks, this is working with version v2.22.3!

Do you know if the Toolbox client will need a similar code change?