HTTPS certificate for private HTTP service?

I am thinking of two ways I might arrive at my goal. For the first of the two proposed solutions, I recognize the fact that the browZer HTTP agent is still incubating and is not yet generally available. As such, assuming it is in a nearly final form, I believe this approach would work when it does ship.

  1. Is it possible to self-host the browZer HTTP agent w/ NF Teams plan? I have an HTTP website served up over Ziti w/ my NF Teams plan. Can I deploy the browZer agent as an HTTPS binding for my normal web browser w/ NF in a self-supported manner, or does this entail a particular configuration of the controller that’s managed by you? If that’s a viable path forward, I’m happy to configure my own private router or an additional controller. I would use a LetsEncrypt certificate and bind it to the HTTP(S) agent’s web server. I could use either the TXT resource record or TXT document challenges in this case.

  2. Obtain a LetsEncrypt certificate through their DNS challenge instead of the public document challenge. The only downside here is that I need to find a way to “front” my web server with a proxy (it’s built in to another app, so I can’t bind the cert natively), and change the Ziti service to go to the new proxy.

1 Like

Thanks for sharing, as this is a great example.

I was doing something close to this a while back, and got stuck at the same DNS challenge.

I did uncover a possible solution, but never explored it because it required a cost.

To purchase a wildcard certificate from a highly credible certificate authority.

These can be quite expensive… so I put it on the back burner until I really needed to do this.

This way… you can have all sorts of other domain names in the SAN… which I believe will resolve your issue… though I could be wrong… as I don’t know all of the details.

If this is just for a private internal use, one work around approach that I found is to create a new private certificate authority… and set this up as a trusted certificate authority with the controller. You can then issue your own private server certificate for the server… that is trusted with the controller… you can you use it over a ziti network.

if you do this… you will still need to do one more thing… which is to add the certificate to the host… so that it recognises the server certificate.

The only downside is that you still need to deal with the client side … but I believe this can be addressed with a bit more work… by handing it over to the team that manages the OS… to make sure the private certificate is rolled out to each of the user machines.

I hope that helps.

Scott

PS. there is one more thing I remember, where you can bundle the certificate authorities together to facilitate trust. I am not 100% sure how it all works, but is something to add into the mix of things to work through a solution.

This is the certbot CLI command that uses the DNS challenge.

sudo certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d "${DOMAIN_NAME}"  # domain may be wildcard

Ref: https://cloudness.net/certbot-dns-challenge/

Prerequisites include:

  1. follow instructions in linked reference to obtain the Python script
  2. provide PyPi module requests to root’s Python or run certbot certonly CLI with user-writeable config and log dirs (see certbot docs for specifics).

Then, to compose the PKCS12 keystore with the issued cert and backing private key I needed to run this command.

sudo openssl pkcs12 -export -in /etc/letsencrypt/live/${DOMAIN_NAME}/cert.pem -inkey /etc/letsencrypt/live/${DOMAIN_NAME}/privkey.pem -name ${APP_NAME} -out /etc/letsencrypt/live/${DOMAIN_NAME}/${APP_NAME}.p12`

Then I needed to configure my server app to use the keystore with the same encryption passphrase I defined when I created the PKCS12 file. Some server apps will use the PEM key and PEM cert instead of a PKCS12 keystore file which basically combines both of those PEM files into a single file with a standard format.

1 Like