This freeCodeCamp article recommends
- setting up a CA server,
- installing the CA root certificate file into the system's trust store, and
- generating a leaf certificate for the project's web server.
Based on my understanding of the TLS handshake for HTTPS, setting up a CA server seems to be an overkill:
The CA servers are never contacted during the TLS handshake (neither by the browser or the server), because the browsers and operating systems have their own copy of CA public keys to verify the certificates' signatures. Thus, when my fictitious CA certificate is added to the list, then the work is done.
A CA server is basically a complex software taking care of certificate operations (e.g., issue, revoke, keep track) and organizational tasks (policies, RAs, etc.), but at the core are the identities of the CAs in the hierarchy (i.e., the certificates and the key-pairs of root and intermediate CAs), which are simply bits stored in files.
The freeCodeCamp article uses the step-ca
and step-cli
tools, where the former is a full-fledged CA server and the latter can be used as an interface to it, but it can also be used "offline" for generic cryptographic tasks.
Specifically, the Create and work with X.509 certificates section in the documentation seems to confirm my thoughts above by providing manual steps on how to create root & intermediate CA and a leaf certificate, all of which can be used right away.