Add support for local TLS.

[ioquatix]

Fixed #34 so that it cleanly applies to the current HEAD.

In addition, here is how to test it:

# In a new rails app, e.g. testapp/

TLS_LOCAL=true TLS_DOMAIN=localhost HTTP_PORT=8080 HTTPS_PORT=8443 RAILS_ENV=production thrust bundle exec bin/rails server

Then you can test it:

> curl -k -v https://localhost:8443/index.html
* Host localhost:8443 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*  subject: O=Thruster Local CA
*  start date: Oct  1 00:52:36 2024 GMT
*  expire date: Sep 29 00:52:36 2034 GMT
*  issuer: O=Thruster Local CA
*  SSL certificate verify result: self-signed certificate (18), continuing anyway.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Connected to localhost (::1) port 8443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://localhost:8443/index.html
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: localhost:8443]
* [HTTP/2] [1] [:path: /index.html]
* [HTTP/2] [1] [user-agent: curl/8.10.1]
* [HTTP/2] [1] [accept: */*]
> GET /index.html HTTP/2
> Host: localhost:8443
> User-Agent: curl/8.10.1
> Accept: */*
> 
* Request completely sent off

[reesericci]

Incredible, thanks - should I close #34 in favor of this?

[ioquatix]

@reesericci I basically just squashed your PR and made a few fixes. You are welcome to close #34 in favour of this if you think that makes sense. You already solved all the tricky problems like constructing the local CA etc.

[ioquatix]

@kevinmcconnell can you please review this PR?

[mdesantis]

Hey there! Is there any chance this PR is going to get merged? It would greatly help in local debugging production-like environments

[ioquatix]

@dhh any chance we can get a review?

[kevinmcconnell]

Thanks for the nudges on this one @ioquatix, and sorry for the slow review, it had fallen off my radar 😬

I think this is a great idea, and I can see how it would be useful. Would definitely like to get this merged. Nice work figuring out the details of creating the authority and certs, it seems to work really well.

I've left a couple suggestions about the implementation. They're mostly minor, but I think it's worth extracting the logic of providing TLS certificates out from Server. I think it'll clarify the logic a bit, but will also separate the responsibilities a bit more, and introduce a seam for testing. Let me know what you think.

[kevinmcconnell]

When doing this, we won't need to create the manager above. It's likely harmless, but it would be clearer to separate the ACME TLS and local TLS support more fully.

Rather than branch on the specific differences, how about introducing an interface that both the local TLS provider, and the autocert Manager implement, maybe something like:

type TLSProvider interface {
	HTTPHandler(h http.Handler) http.Handler
	TLSConfig() *tls.Config
}

Then we can create either a local provider or an autocert manager (depending on the config), and wire it up the same way in either case.

[ioquatix]

I'm sorry but I don't know enough about Go to implement this without significant help, so maybe it's better if you either add commits to this PR to do what you want or merge it as is and then refactor it.

[reesericci]

I think this sounds great @kevinmcconnell. Unfortunately I don't have the bandwidth to implement this at the moment but a +1 from me on the common interface as a nice abstraction.

[kevinmcconnell]

No worries @reesericci, I'll try to wrap this up when I have a bit of spare time. Thanks for getting this work started.

[kevinmcconnell]

I don't think this needs to be specified, as HTTP/2 support should be enabled automatically.

[ioquatix]

IIUC, it needs to be specified for ALPN.

[kevinmcconnell]

It's not necessary because the HTTP server includes h2 in its available protocols by default.

[kevinmcconnell]

As mentioned above, I think it's worth introducing a common interface for the two types of TLS provider. At which point, we can move the work of getLocalAuthority/getLocalCertificate into its own type that implements that interface.

That would also give us a handy place to add some test coverage for GetCertificate.