Vjylku

My company is creating presentation software. When in use, presenters sign on through an HTTPS enabled web site to send text, documents, authentication tokens, etc.

My question is this: How do I enable HTTPS communication when:

1. There is only a dynamic internal IPv4 (196.168.0.x) address and some IPv6 address.


2. The web site might be an internal-only site. (https://letsencrypt.org/ can't reach it.)


3. No manual steps allowed. The customer installs the software and it is good to go.

For those interested, I'm using the C# control Httplistener and PowerShell.

Some of my research:

1. https://stackoverflow.com/questions/11403333/httplistener-with-https-support


2. https://www.c-sharpcorner.com/article/how-to-enable-https-on-your-website-for-free/


3. http://www.howto-expert.com/how-to-get-https-setting-up-ssl-on-your-website/


4. https://stackoverflow.com/questions/22230745/generate-self-signed-certificate-on-the-fly

If your internal domain name matches an external domain name (e.g. sales.corp.example.com) you can still get a certificate from most public CAs, as they will accept ownership of example.com assuming whoever owns admin@example.com/webmaster@example.com/whatever is happy to approve your certificate request. The site itself does not need to be accessible over the internet. There are other providers that implement Let's Encrypt's ACME protocol so if you can't abide by their requirements you may still be able to use the same protocol with a different provider.

If no part of your internal domain is publicly resolvable (e.g. you used a fake TLD like sales.corp.example.local), then your only option is to use an internal CA.

If you want to use an internal CA to sign your certificates, then you'll need to install that CA as a trusted provider on all your devices. And if you want to do this "properly" then it's a fairly extensive thing to set up (typically you have a root CA that lives offline that signs a subordinate CA that actually signs your certificates). You'll need processes in place to rotate the root certificates when they come up for expiry and a way to distribute them (if you're fully integrated on a Windows domain with no Linux devices, this is actually not that hard).

Once upon a time it was possible to go to a CA and ask them to issue a certificate for an internal domain and go through a lengthy and expensive validation procedure, however new procedures introduced on 1st July 2012 banned any CA from issuing any certificate containing an internal common name from 2015, and revoke existing certificates by 2016. So unless you have a time machine that's not going to happen.

As an aside:

The customer installs the software and it is good to go

That's highly unlikely to ever happen. I've installed a lot of enterprise software over the years, and TLS configuration is something that I have always had to do by hand. There's a bunch of reasons why you cannot assume you can configure certificates automagically:

• Customer may not have internet access from the host so you can't contact an external authority


• Customer may have a very restricted list of approved CAs, and you have to have a certificate issued by them


• Customer may require auditing of all certificates being issued for internal hostnames

In fact if your appliance was on my network with an automatically configured, valid, trusted SSL certificate out of the box I would be extremely suspicious. There are plenty of appliances that allow you to one-click configure Let's Encrypt but it is never, ever a default. It is always opt in.

No manual steps allowed. The customer installs the software and it is
good to go.

If you do not control end user devices, no additional steps means you must use a CA already in their root certificate stores (OS or browser). The customer's internal PKI could sign your certificates, but that assumes they have one, and it won't work for unmanaged devices. Which leaves a well-known "public" CA.

The web site might be an internal-only site. (https://letsencrypt.org/
can't reach it.)

Ownership challenges need not be from the host that gets the certificate. You mentioned Let's Encrypt, their DNS challenge can be done from any Internet visible DNS. Including wildcards, so you can issue *.present.example.com.