Enabling HTTPS should mention buying a domain

[pinobatch]

The article "Enabling HTTPS on Your Servers" gives a list of steps to enable HTTPS on a web server. For convenience, I'll summarize:

1. Create a key pair
2. Generate a CSR
3. Submit this CSR to a CA to receive a certificate
4. Configure your web server to use this certificate.

But it is missing one vital step: purchase a domain name from a domain registrar in order to give your server a fully-qualified domain name (FQDN).

The Baseline Requirements that all widely trusted CAs follow require servers to have an FQDN in order to be eligible for a certificate. In particular, the Baseline Requirements forbid issuing a certificate that covers a hostname within a made-up top level domain (TLD), such as .local or .internal, or an IP address within a range reserved for a local area network (LAN), such as 192.168/16.

Web servers accessible through the Internet have an FQDN as a matter of course. But web servers internal to a LAN may not. Such a private server may have any of several roles:

• A server used for testing a web application before deploying it publicly, particularly on mobile devices where it is impractical to run a web server on localhost
• The configuration interface of a router, printer, or network attached storage (NAS) appliance
• A web application intended for access by guests at a museum or other facility through devices brought by guests (BYOD) and associated to said facility's WLAN

Both Mozilla (in "Deprecating Non-Secure HTTP") and a Let's Encrypt representative (in an AMA on reddit) have acknowledged that securing these nameless private servers is a hard problem, but they haven't described particular solutions that scale.

[kosamari]

Will take a look at this as part of security content audit

[pinobatch]

For the benefit of those searching for this issue, FQDN-less servers are associated with the following protocols:

• Zero-configuration (Zeroconf)
• Multicast DNS (mDNS, RFC 6762, Bonjour, Avahi)
• DNS Service Discovery (DNS-SD, RFC 6763)
• Web Services Dynamic Discovery (WS-Discovery)
• Service Location Protocol (SLP)
• Simple Service Discovery Protocol (SSDP)