I’ve got a native app (it runs on Linux/OSX/Windows) that serves webpages to smartphones on the local network. Users run the app, then point their phone’s browser at the app’s server. For example: http://192.168.1.10 The phones now interact with the app through the server it’s running. The web pag…

Note: I edited the thread title to reflect more clearly what the thread is about.

Thanks! Yea that’s looks like it will work for home users on the internet. Unfortunately my software is also used in a bunch of museums and installations. In that case there is no internet. Users connect to the WiFi, using fake DNS and Captive Portal support they either wait for the captive portal…

Actually could Let’s Encrypt help with the second path I mentioned above. That second path is as follows My native app (OSX/Win/Linux) is also used in a bunch of museums and installations. In that case there is no internet. Users connect to the WiFi, using fake DNS and Captive Portal support they …

If you can get the museums to make a change to the browser configuration you can issue certs without the involvement of an external CA: you can make your own CA for your application (perhaps just by using a few openssl command line commands, among other possibilities) and then ask the museums to add…

[image] greggman: It seems like if the browser is going to check certificates and doesn't need to go online to do it I can include a "private" certificate directly in the app, of course that means anyone can steal it and use it for whatever they want and eventually it will probably get banned/de…

I seem to keep failing to make it clear how my stuff works. The parts are A web server. I keep calling this an app because it installs on PC/OSX/Linux. User’s smartphone browser (Safari / Chrome) A WiFi router No internet is used. No apps on the phones. It all works now. Users are going …

In this situation I would recommend you use a public domain you control. For this example, I’ll refer to a single installation for the fictional MOAA, Museum of Awesome Art: moaa.yourdomain.tld Set up a simple webserver on the public Internet at moaa.yourdomain.tld Use the Let’s Encrypt client to…

This sounds like it will work as long as the user’s phone’s browser doesn’t need internet access to verify the certificate/s.

No it does not. Unless it checks for some revocation information, but I think this is not done or if it does most browsers still allows the connection although the check failed. (which is - principally said - bad of course)

There are some configurations in which either browsers or servers would want Internet access to confirm in some way that the cert hasn’t been revoked. However, it’s not yet common for this to be mandatory when accepting a cert, so the method that @jcjones proposes should currently work fine for this…

Certificates for hosts on private networks

Issuance Policy

waspinator January 17, 2019, 2:02pm 37

which top level domains would this support? Would it work with foo.example.local?

Certificates for many user-controlled subdomains

Topic		Replies	Views
Completely LOCAL! Help	31	8818	January 3, 2023
A public cert for localdev.letsencryrpt.org Server	22	5886	April 20, 2016
SDK responding to localhost on SSL Help	19	1666	November 20, 2020
Certificates for many user-controlled subdomains Issuance Policy	20	9843	April 13, 2016
Trusted SSL for private networks Help	28	26950	April 17, 2021

Certificates for hosts on private networks

Related topics