-
Notifications
You must be signed in to change notification settings - Fork 43
SSL TLS Certificates
Browsers are increasingly calling attention to password fields present on non-HTTPS pages. The actual security necessity of using HTTPS on internal networks is debatable, but setting up certificates might be the path of least resistance in getting rid of browser nags. Bear in mind this is not the only or necessarily best way to deal with certificates certificates.
Install OpenSSL. This is probably already present on any *nix machine. The instructions probably work on Windows, too, but creating certs for Windows machines on *nix and transferring them over the network or by USB key or whatever should work too.
Generate a self-signed certificate and key.
openssl req -x509 -nodes -newkey rsa:4096 -keyout key.pem -out cert.pem -days 3650
This will create a private key named key.pem and a certificate named cert.pem. The process will ask a few question. When it gets to Common Name (CN), enter the host name (or IP address) of the machine this certificate is for. Whatever name is used to browse the server needs to match the name listed in the certificate. The days option sets the certificate expiration - 10 years in the example. Copy the two pem files to somewhere on the machine that will use the certificate. The webserver's configuration directory is a sensible choice.
Configure your web server to enable SSL using the specified keys. This will depend a bit on your webserver. Documentation for your specific distribution will be more detailed.
Using Apache:
Your Apache installation likely has a skeleton SSL configuration already in place. Possible locations include sites-available (Debian), conf.d (Red Hat), extra (Windows). The file you're looking for likely has ssl in the name. In it will be a Listen 443 directive and/or a VirtualHost using port 443.
Find the line that says SSLCertificateFile and change the value to the path to your cert.pem file. Then find the line that says SSLCertificateKeyFile and point that to your key.pem file. Do whatever is necessary to make sure this config file is enabled - possibly nothing, possibly some symlinking - and restart the apache service. If the machine responds to HTTPS requests, it worked. You'll probably get a big scary certificate warning page though (see Step 3).
Using nginx:
Your nginx installation likely has a skeleton SSL configuration already in place. It might be in its own configuration file or might just be in the regular config file (possibly commented out). You're looking for a server block that says listen 443. Uncomment the whole block if necessary. Change the ssl_certificate line to the path to your cert.pem file and the ssl_certificate_key line to point to your key.pem file. You may also have to copy bits of configuration like FastCGI from the HTTP server block to the HTTPS server block. Do whatever is necessary to make sure this config file is enabled - possibly nothing, possibly some symlinking - and restart the nginx service. If the machine responds to HTTPS requests, it worked. You'll probably get a big scary certificate warning page though (see Step 3).
Import your certificate into browser(s) to eliminate error and warning messages. In Chrome you need to import cert.pem as a trusted root and restart the browser. The certificate then shows as valid. In Firefox this same procedure does not work and produces an MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY error. Adding a permanently stored exception does eliminate the nag messages on password fields but in the address bar the certificate still says invalid.
If you don't have internal DNS servers to provide custom names, it's possible to assign names to IPs on the client side via the hosts file: /etc/hosts on OS X or Linux and C:\Windows\System32\drivers\etc\hosts on Windows. Repeating for every client machine is a little tedious but is typically a one-time task.