Make it possible to add SSL keys per site. For this we need to start a SSL listener for each site separately. We also need to add a ssl port number to the ssl config. Keys could be placed in the ssl directory, using default names.
where sitename is the name of the site.
On a side note.
openssl nowadays creates PKCS#8 private keys (starting with -----BEGIN PRIVATE KEY-----).
Erlang new_ssl wants PKCS#1 private keys (starting with -----BEGIN RSA PRIVATE KEY-----).
When new_ssl receives a PKCS#8 key then it decodes to , resulting in strange errors.
-----BEGIN PRIVATE KEY-----
-----BEGIN RSA PRIVATE KEY-----
I think we should do a quick check on any private key if:
When not then we could suggest the command: openssl rsa -in sitename.key -out sitename.pem
openssl rsa -in sitename.key -out sitename.pem
Sounds good, although I've not yet used SSL with zotonic...
Is that possible to run virtual hosts with ssl with different certificates on port 443. In the past (read way back) I had to arrange a separate ip-address per virtual host.
@mmzeeman did you miss the ssl port config option? I guess that either different IP's /or/ different ports would work?
I think it would be wise, as part of these SSL tickets, to make a documentation page on how SSL with zotonic works, and to configure it and what the different options are.
+1 There are so many ways to do this. With a reverse proxy in front, port mapping, etc etc.
Port configuration in general need to be covered.
And SSL makes it even more hairy. @kaos was right that I propose to add a separate listener on a separate port for every site. With port mapping you can then select which one is the "happy one" on 443. Though you need to configure that the outside port is 443 (just like with 80) so that we don't add the port to URLs.
So it is still that way, just one virtual server per ip will be the happy one running on port 443. (sounds like a protocol design flaw).
Btw, wouldn't it be easier to place the keys and certs directly inside the config file? Keys and certs are all printable text. Relying on separate directory with separate files can cause configuration problems.
I was thinking to put them in files because:
I agree with @mworrell ; all web servers I know of do it this way, so ppl are used to setting up the configuration like this.
It also makes it easier to manage the keys when you don't need to touch the config file.
And can work with them directly using other tools (e.g. openssl).
However, perhaps it could be useful to have the option to put keys in the site config file, and then zotonic could export them from the config file if it can't find the key files.
@mworrell Forgot about new_ssl, openssl wraps the whole hoop jumping part.
For now I keep it simple and put the keys in file in the ssl directory.
@mmzeeman Mochiweb uses the Erlang ssl library, which is new_ssl, isn't it?
Personal side note: For end users ssl solves the trust problem in the worst possible way. The protocol was designed with the certificate business in mind as it was supposed to be Netscape's moneymaker. Unfortunately it is still "best practice" and we have to deal with it.
@mworrell From what I read: new_ssl is now the default ssl implementation from R14 and up.
mod_ssl: Added mod_ssl, enables ssl certs per site. Removed ssl from …
…the core. Tuned dispatch rules for more secure usage. Fixes #434. Fixes #433.