HTTPS Setup for masspirates.org

General Procedure

masspirates.org has a self-signed X509 certificate. Since our cert wasn't issued by one of the well-known members of the certificate cartel, browsers will give a warning about "not being able to identify the site's identity". People accessing our site will have to make the decision to trust us (as opposed to having their web browser make that decision for them).

MFPL supports subject alternative names, so we were able to set up HTTPs without getting a dedicated IP address. However, one has to tweak openssl's configuration, in order to generate a certificate with the x509v3 subjectAltName extension.

Here's what to change in openssl.cnf (or, a local copy of openssl.cnf)

 sunny:~$ diff -u /etc/ssl/openssl.cnf .openssl.cnf
 --- /etc/ssl/openssl.cnf        2013-12-18 08:37:55.000000000 -0500
 +++ .openssl.cnf        2014-02-27 20:28:27.728143498 -0500
 @@ -63,7 +63,7 @@
  cert_opt       = ca_default            # Certificate field options
  
  # Extension copying option: use with caution.
 -# copy_extensions = copy
 +copy_extensions = copy
  
  # Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
  # so this is commented out by default to leave a V1 CRL.
 @@ -122,7 +122,7 @@
  # WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings.
  string_mask = utf8only
  
 -# req_extensions = v3_req # The extensions to add to a certificate request
 +req_extensions = v3_req # The extensions to add to a certificate request
  
  [ req_distinguished_name ]
  countryName                    = Country Name (2 letter code)
 @@ -220,6 +220,7 @@
  
  basicConstraints = CA:FALSE
  keyUsage = nonRepudiation, digitalSignature, keyEncipherment
 +subjectAltName = DNS:masspirates.org
  
  [ v3_ca ]
  
 @@ -233,11 +234,16 @@
  
  authorityKeyIdentifier=keyid:always,issuer
  
 +basicConstraints = CA:false
 +keyUsage = nonRepudiation, digitalSignature, keyEncipherment
 +subjectAltName = DNS:masspirates.org
 +
 +
  # This is what PKIX recommends but some broken software chokes on critical
  # extensions.
  #basicConstraints = critical,CA:true
  # So we do this instead.
 -basicConstraints = CA:true
 +# basicConstraints = CA:true
  
  # Key usage: this is typical for a CA certificate. However since it will
  # prevent it being used as an test self-signed certificate it is best

The key points are req_extensions = v3_req, and the lines added to v3_ca. (I added the same three lines to v3_req, but for self signing, only v3_ca seems to matter.)

Next, generate the certificate

 openssl req -new -nodes -x509 \
   -out masspirates.org.crt \
   -newkey rsa:4096 \
   -keyout masspirates.org.key \
   -config ~/.openssl.cnf \
   -days 730

Here is our fingerprint

 0 sunny:~$ openssl x509 -fingerprint -noout -in masspirates.org.crt 
 SHA1 Fingerprint=D5:3F:E6:C6:0B:CC:1B:81:A4:C5:1C:80:14:29:61:45:FF:C3:59:A5

Via MFPL control panel, add an https web configuration. The https configuration should contain everything in the http section, along with the following lines

 SSLEngine on
 SSLCertificateFile /PATH/TO/masspirates.org/include/cert/masspirates.org.crt
 SSLCertificateKeyFile /PATH/TO/masspirates.org/include/cert/masspirates.org.key

For mediawiki to work properly, you'll need to change $wgServer.

 -$wgServer           = "http://masspirates.org";
 +$wgServer           = "//masspirates.org";

Mediawiki calls this a "protocol neutral link". Some browsers will refuse to fetch both http and https urls from the same hostname. The protocol neutral server avoids this.

Wordpress Issues

Unfortunately, wordpress seems to insist on absolute URLs - you can't simply say "my site address is /blog/". That's a perfectly legitimate thing to do in the web development world, but not for wordpress. Seems like we have to be all http, or all https. Or, do something like this: http://wordpress.org/support/topic/get-wordpress-running-on-both-https-http.

I've found a number of posts describing the same issue: problems with trying to make both http and https work with a wordpress sites. Several of these attribute the issue to shortcomings in wordpress core.

So, I suppose we use https for our own logins. Until we get a cartel certificate, and can force traffic over https.