Problem setting up HTTPS listerner via winhttp

EventStoreDB
#1

Hi,

I’ve got a 3 node cluster up and running using TCP, secure TCP and HTTP, but I’m struggling to get HTTPS working.

I’ve created a certificate using our internal CA server, it’s installed with the private key (and the chain validates) in the LocalMachine \ Personal store, and it’s currently being used fine for the secure TCP listener. I’ve also registered the certificate in winhttp using:

netsh
http add sslcert ipport=[server_ip]:[server_port] certstorename=MY
certhash=[thumbprint] appid={00000000-0000-0000-0000-000000000000}

However, no matter what I do next, the EventStore admin ui and the client api still respond on “HTTP://[server_ip]:[server:port]” and get an error from “HTTPS://[server_ip]:[server:port]”.

I understand this is probably more of an issue with the Windows winhttp configuration than specifically with EventStore, but I was wondering if there’s a step-by-step walkthrough from first principles on how to enable HTTPS access to EventStore? The EventStore documentation at http://docs.geteventstore.com/server/3.9.0/setting_up_ssl/ seems to refer to the TCP listener rather than the HTTP endpoint.

If it makes any difference, I’m using Windows Server 2012 R2 and EventStore 3.9.2.

Cheers,

Mike

#2

Exposing GES (or any other application server) directly to the web is usually not a good idea. What most people do instead is have SSL terminate at a proxy like nginx. That being said, I think you want to look here instead: http://docs.geteventstore.com/server/3.9.0/architecture-setup/

#3

I had similar problems in the past; we did end up terminating at our load-balancers, as Joao suggests in his reply. However, you might try changing the port to a more standard HTTP/HTTPS port number, like 443, or 4430. Windows security? Group policies? Can interfere here, even with URL ACLs and a user context with heavy permissions.

#4

Hi João,

Thanks for the info.

For context, this will be an internal-only service, but it’s hosted at a 3rd party managed service provider with a stretched VLAN.

As it’s highly sensitive data (which is encrypted at rest at both ends using NTFS / EFS) we want to make it resilient to attempts to run network tracers by malicious staff at the hosting provider while data is in-flight as well. Obviously even this set up isn’t bullet-proof as the staff have local admin rights anyway, but it’s another box ticked in the annual security audit.

Cheers,

M

#5

Hi Andy,

It’s possible that some of our more exotic use of Group Policy, antivirus and internet proxy are causing some issues. I certainly have problems with some SSL websites from my desktop.

I think might try spinning up a vanilla Windows VM and see if I can EventStore working with HTTPS on that to rule out our corporate paranoia. I’ll post back here with an end-to-end repro if I get it working.

Cheers,

M

#6

Ok, so I think I’ve got this working. The breakthrough was finding this post:

https://github.com/EventStore/EventStore/issues/802

Basically, you configure winhttp / http.sys to listen on a DIFFERENT port when it uses the ssl certificate. Then, your client needs to connect to the “managed” https port and winhttp will terminate the ssl connection and forward the request on the EventStore ExtHttpPort. This is probably painfully obvious to a lot of people but as a newcomer to EventStore I’ve been baffled for a painful couple of weeks.

Note that when you start the EventStore.ClusterNode.exe you need to tell it what port winhttp is listening on for ssl by specifying the ExtHttpPrefixes argument somewhere (i.e. command line, env vars, config yaml). You also need to block the external HTTP port using Windows Firewall or whatever network management tools you’re using if you don’t want it to be available to clients.

For completeness, here’s some Windows Command Prompt stuff to sort of repro what I got working: