Allow to replace the server cert at runtime

[iftahbe]

Right now, the SSL certificate that Kestrel will use is here:

https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Kestrel.Https/Internal/HttpsConnectionAdapter.cs#L25-L26

There are certain scenarios that we want to support replacing the certificate while the server is still running. This can be done quite easily if we could set the _serverCertificate so all new connections will be able to use that.

Scenarios for that include using Let's Encrypt certificates and not having to restart every 3 months.

While making it public is one option, I think it would be better to not hold a reference to the _serverCertificate from the options but use the value in the options itself. That will mean that the caller could hold on to the options and change the certificate value used without messing with any internal state.

[Tratcher]

As an alternative, we hope to get SNI support at some point and one of the API proposals is for a callback where you can select your own cert for each connection. This would allow you to change the cert dynamically.

[Drawaes]

I would say at worst, this should wait until the "option bag" for SslStream is completed, then you could expose that or pass it into Kestrel. At best you will get the callback as mentioned above...

[Tratcher]

I doubt the new options bag will be exposed by kestrel APIs. For now it's Core only.

[davidfowl]

The middleware could expose a callback today but before we do anything, somebody should hack together a lets encrypt connection adapter for kestrel so that we can see all of the touch points.

[ayende]

I implemented a very rough draft here:
https://github.com/ayende/Kestrel.LetsEncrypt

No error handling and this is mostly to see that I could do it.
Pretty much the only thing that I actually needed to do was to change the way Kestrel is getting the certificate. But in order to do that I had to pretty much bring all of Kestrel.Https

[davidfowl]

@ayende Sweet!

But in order to do that I had to pretty much bring all of Kestrel.Https

Yea, but that's not a big deal it's only a few files. This should also let us prove out if a callback is enough.

[ayende]

A callback for the certificate would be enough, yes.

[davidfowl]

This looks kinda crazy https://github.com/ayende/Kestrel.LetsEncrypt/blob/f9facd8159f61aecd5053d49776ad3538d460b92/Kestrel.LetsEncrypt/Internal/LetsEncryptCertificateFetcher.cs.

[ayende]

The major issue here is that we need some way to prove to Let's Encrypt that we are the owners of the domain. We can do that in various ways, but the easiest from our perspective at this point is to use the http-01 challenge.

This basically means that we ask Let's Encrypt for a certificate, and we need to prove we own this domain. We do that by getting a token from Let's Encrypt and asking it to call back to us (over HTTP, using port 80) and thus proving how this can happen.

I thought about having a kestrel instance that is always on using port 80, but it seems easier to just open it to the few seconds we need to do the verification.

It would probably be easier to do this using DNS, but that require you to use some API and bind you to a specific DNS provider.

I couldn't find a way to make Kestrel route based on the listen source anyway, and I don't think it matters too much.

[Drawaes]

https://github.com/dotnet/corefx/issues/22510

Can't use protected data. Like secure string it either throws or just isn't (secure)

[Drawaes]

Let me qualify that. On anything other than windows

[ayende]

The actual problem here is that we need to persist the cert to disk. We can do that with OS permissions so only the current user can touch it, or provide callbacks to the user to handle caching the certificate if they want to customize that (such as storing in a vault).

[Drawaes]

Why does it need to go to disk? Can't you just use the bytes [] ?

[ayende]

Let's Encrypt encourages you to keep the same certificate around, rather than renew it on every start.
Otherwise, you might hit rate limits.

[Drawaes]

I guess that's a problem for people with crappy code that restart often of which I am sure yours is not ;). Maybe make an option to "persist certificates to disk"