running Seq server against two domains and two certificates

[bytejunkie]

our specific situation is that we currently access Seq from a whitelisted IP over the internet, but i need to make it more secure.
I've tried adding another cert for an internal address. I've used seq bind-ssl --thumbprint="thumb" --hostname="hostname" to bind the two certs to the two urls. but it doesnt seem to work for the new url.

should this work? if so i know to keep digging.

[nblumhardt]

Hi Matt, thanks for your message.

bind-ssl will only apply if your Seq install is using HTTP.sys; if it's using Kestrel, then Seq will look in Personal/Certificates for matching certs:

https://docs.datalust.co/docs/https-on-windows

To find out which web server you're using, seq config get -k api.webServer will print Kestrel if it's in use. Otherwise, the instance is using HTTP.sys.

Let me know if this helps :-)

[bytejunkie]

this command didnt work which made me check versions and i saw we were quite a way out of date. i eventually created a cert for both sites and bound that until i can get the server upgraded.

[n1njab0b]

I ran the seq config get -k api.webServer command and received a blank response, which I take to mean that my installation is using HTTP.sys.

With that established, after reviewing the documentation, it remains unclear to me if/how Seq supports binding to multiple SSL certificates. I want to minimize downtime on my production server, so I just want to determine beforehand if it's supposed to be supported.

Currently, our api.listenUris is just set to "https://localhost" and we have that bound to a single, internally signed cert (e.g. seq.internaldomain.local)

What we want to do is also accept traffic from a public DNS name (e.g. seq.exampleserver.com)

Would the following commands provide the desired result?

seq config set -k api.listenUris https://localhost,https://seq.internaldomain.local,https://seq.exampleserver.com
seq bind-ssl --thumprint=$INTERNALCERTTHUMBPRINT --hostname=seq.internaldomain.local
seq bind-ssl --thumprint=$EXTERNALCERTTHUMBPRINT --hostname=seq.exampleserver.com
seq service restart

Assuming this is possible, it's not entirely clear to me whether that first command to change the listenUris is even necessary, given that it currently works the way it is using our internal domain name.

Thank you for your time and consideration!

[nblumhardt]

Hi @n1njab0b, thanks for the ping.

I don't think that first seq config line will be necessary in the case you're talking about, assuming everything lines up to support SNI on the server (how incoming TLS requests for different hostnames are handled, which is an HTTP.sys feature).

The main gotcha I'd look out for is that if there's an existing binding without --hostname specified, you might find that blocks creation of further hostname-specific bindings. The bind-ssl command just forwards to netsh behind the scenes, so any errors you receive will have been generated by it.

The only way to be completely sure it'll work is to make the change on a staging/non-prod machine with an identical setup first; otherwise, making sure there's a maintenance window scheduled to cover any downtime would be judicious :)

Hope this helps, and if you hit anything nasty, Seq Support (running in AEST) will be a quicker/more reliable route for quick help than this ticket. Cheers!

[n1njab0b]

Thanks so much @nblumhardt ,

The gotcha you warned me about makes sense. I don't see anything in the bind-ssl documentation providing a means of "clearing" or resetting the bindings. I think I might try just adding the hostname=seq.exampleserver.com and leaving the other default intact since that is already working.

I'll report back my success.

Cheers back atcha.

[n1njab0b]

Worked like a charm!

All that was needed was the single seq bind-ssl --thumprint=$EXTERNALCERTTHUMBPRINT --hostname=seq.exampleserver.com command. The existing binding remained as the default, while this new binding was specific to the hostname, which is exactly the behavior I was looking for. I did not even have to interrupt production with a restart of the service.

Thank you for your time and assistance @nblumhardt !