How can I create a certificate for a server that will never be connected to the Internet

I am a tech enthusiast and need to set up certificates for my home network. I plan to use Rockylinux, Ubuntu and Windows computers. Some of my web browsers and other client applications refuse to connect if the host application does not have a certificate. I dont have an internal private web server yet, but may do soon.
How do I generate a certificate if I am not on the Internet for my private applications?
Can I generate certificates if my private computers are never and will never be connected to the Internet?
Thank you

My domain is: myhome

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version): Rockylinux

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Dont know

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Dont know

To have a publicly trusted certificate (like the ones Let's Encrypt issues), you must own a public registered domain name. That bit is not negotiable.

With a public registered domain name, you can obtain certificates using the DNS Challenge, for which you need outgoing internet access (to talk to Let's Encrypt's API and to talk to your DNS Provider's API), but you do not need to expose your private network to incoming connectoons.

You do not have to use a publicly trusted certificate. You can create self-signed or use a private CA which is local to your network. For this, you don't need Let's Encrypt, you can do it on your own computer using offline tools. However, it that means you will need to configure every system to trust those certificates explicitly, since they will not be trusted by default.



You can download pre-compiled binaries, or build from the Go source code. I've done both, and the results are excellent.

The binary generates it's own CA certificate, and installs that in the OS security store. It can optionally add it to your JDK keystore and the Firefox keystore. Google Chrome uses the OS keystore. It also saves its CA cert to the filesystem.

You then tell it the Common Name and Subject Alternative Names, and it generates a certificate and key. I typically just give it my server hostname and IP (if static).

Always take "random advice" (especially from new users) with a grain of salt [and add plenty of due diligence]:
VirusTotal - URL - 41ae17dba4cee731ab97404e3bf018708bb37bc2d39b8d446d49ba63506ae0e6



Filippo Valsorda is a pretty prominent applied cryptographer:

His tools are useful!

Always take "random advice" (especially from new users) with a grain of salt

I 100% agree. Do not run any commands that you are not absolutely certain are safe.

Having said that, you could follow the GitHub link I provided, and check it out yourself. Like I said, the source code is available, so if you know Go, you should be able to determine if the project is worth checking out. It only has 40 THOUSAND stars, and 2,100 forks. You never know if upstarts like that are safe or not.


You never know if someone updates the code with malice.
I would not recommend running anything precompiled.
That said, we all run operating systems (we didn't compile) - LOL


It seems the Windows EXE's are problematic:
VirusTotal - File - d2660b50a9ed59eada480750561c96abc2ed4c9a38c6a24d93e30e0977631398
VirusTotal - File - 793747256c562622d40127c8080df26add2fb44c50906ce9db63b42a5280582e


Wouldn't be the first time a github repo contains malware in one of the binaries due to a hack.


Which has little to do with @BigGuyWhoKills
[who is the one here pushing the product here]

His choice of compilation software and final verification process leaves doubt in skills outside cryptography.


+1 for mkcert. Very useful tool for local certs. I've used it a few times, though none of the precompiled binaries. But if we look at the GitHub Actions task for the binaries, it's pretty much just the binary produced by go build (mkcert/release.yml at master · FiloSottile/mkcert · GitHub)*.

Though if you're that paranoid, just run go build yourself and be happy. The main code of the tool is around 400 lines of code (plus a bit extra for command line handling and trust store integraton).

False positives in AV software happens, it's nothing unusual. They use heuristics and Go binaries with similar dependencies tend to look similar.

But it's his software. Filippo is the guy who secures the software we use every day. He used to be the cryptography lead for Go - the entire TLS 1.3 implementation in Go, used in i.e. Boulder is his work. He is also a contributor to RFC 8446 and much, much more.

Based on how he does password management, he's one of the last guys I expect to get hacked. But sure, everything is possible in this world.

*The GH Actions script uses a slight variant of the command for cross-compilation, plus flags to add version information during compilation, so it's not exactly go build.


I see two possibilities:

  1. SecureAge and Cynet found a virus (one of them was 9 months ago) that none of the other engines can detect
  2. SecureAge and Cynet are showing user-reported files as "Malicious".

I'm leaning towards the second. It is possible that the software found an unknown executable and asked the user what to do with it. The user forgot that they downloaded it, and flagged it as malware. This would be a false positive.

I'm not saying this is proof that the files are safe. But if 67 of the 69 virus scanners can't detect a malicious file after it's been in the wild for 9 months (and therefore not a zero-day), and the scanner that flagged it doesn't even have a name for the virus, then I think it's safe to say this was a false positive.

While that is possible, the malicious pull request would have to be accepted by one of the repo admins. This seems unlikely for a project this reputable.

All that is good and well.
A person could be the best ... brain surgeon in the world.
That doesn't mean I should trust them to fly a plane!

What I mean is, if the compiler that was used to make the executables was compromised, then all of its' output is compromised. It matters not how great the input was that it received.

So, I still stick with "it's a bad idea to provide precompiled binaries" - because they are near to impossible to validate 100%. While providing source code stands a much better chance. That should be the first choice.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.