0

I have two WebAPI applications in my cluster. Both apps run on each node. They both use asp.net core and Weblistener. Following the advice here I have set them both up to listen for http and https on port 80, and 443 respectively.

Https is secured using the same certificate and is set up using the, er, endpoint binding(?) as discussed here. I got it working fine with a self signed certificate, but a problem arose when it came to changing the certificate to a proper one. Effectively simulating a certificate rollover.

I added the new certificate to the key vault and deployed it to the cluster. When it came to republishing my applications, with the new certificate reference, it would fail with this error ConfigurePortCertificate: httpsPort=443, certStoreName My, certfindvalue {SSLCertFingerPrint}, error AlreadyExists. Which kind of makes sense now..

Since both applications are running on each node, and we attempt to update one of them the following happens:

  1. WebAPI1 has Cert_A bound to https:443.
  2. WebAPI2 has Cert_A bound to https:443 (which is fine, they're the same cert)
  3. Attempt to update WebAPI1 with Cert_B.
  4. Publishes to cluster, attempts to bind Cert_B to https:443
  5. Error because a different cert (Cert_A) is already bound to https:443

The only workaround I found for this is to take every system which uses Cert_A on https:443 offline, and republish all the apps using the new Cert_B.

This is pretty unacceptable (as in, I'm clearly doing something wrongly) to have to take major parts of the system down to change certificates.

What are my options here?

Does Kestrel manage https differently? Would I run in to similar issues by doing something like... instead of having the certificates hosted locally (i.e. through VM provisioning), I could request the latest certificate from keyvault. I could provide Kestrel with a certificate provided by an unversioned URL to key vault (which gets the latest certificate). Then I suppose all I'd need to do is cause the services to restart (publish an upgrade for example) and they'd start using the newest certificate. However, I understand Kestrel is not currently "supported" to be used for externally facing web servers.

Would I be best off either

  1. Using a gatewaty (e.g. Application Gateway) and hosting all my WebListener services on different ports, secured with HTTPS
  2. Using a gateway and use Kestrel, either different or same ports
  3. Using a https secured gateway and have my services run on different ports, not worry about https internally.

Or is there a simple solution to my problem which I don't realise?

Thanks in advance!

I apologise for any incorrect terminology, please do correct me.

Community
  • 1
  • 1
Mardoxx
  • 4,372
  • 7
  • 41
  • 67

1 Answers1

0

There's a reverse proxy built into ASF. It can be configured to use SSL and perform SSL termination. That's a very simple solution.

http(s): The reverse proxy can be configured to accept HTTP or HTTPS traffic. In the case of HTTPS traffic, SSL termination occurs at the reverse proxy. Requests that are forwarded by the reverse proxy to services in the cluster are over http. Note that HTTPS services are not currently supported.

LoekD
  • 11,402
  • 17
  • 27