Setting up https with a self-signed certificate on Apache

The issue is more likely to lie with your vhost configuration.

The ssl_error_rx_record_too_long error can be produced by initiating an HTTPS session against an HTTP resource. Such as - https://host.name:80.

The approach I've used in the past is slightly different to the one you detailed. The instructions below were originally detailed in this post I found whilst looking how to set up ssl: Step by Step Installation Of Subversion Over Apache/SSL Authenticating through Active Directory (SSPI)

To summarise:

1. Under apache\bin create openssl.conf and set its contents as follows:

   [ v3_ca ] 
   subjectKeyIdentifier = hash 
   authorityKeyIdentifier = keyid:always,issuer:always 
   basicConstraints = CA:true 
   [ req ] 
   default_bits  = 1024 
   default_keyfile  = server.key 
   distinguished_name = req_distinguished_name 
   attributes  = req_attributes 
   x509_extensions = v3_ca  
   string_mask  = nombstr 
   [ req_distinguished_name ]  
   commonName  = Common Name 
   commonName_default = My Server Name 
   [ req_attributes ]

2. Open a command prompt up, navigate to apache\bin and run the following command:

   openssl req -config openssl.conf -new -out server.csr

3. When prompted enter a pass phrase and then a second time to verify.

4. You will then be prompted to enter a Common Name [My Server Name]. Enter the name of the machine

5. Next remove the passphrase from the private key with the following command (note this may give a warning about not being able to find openssl.conf - this can be ignored):

   openssl rsa -in server.key -out server.key

6. Enter the previously used passphrase when prompted

7. Next create the self signed certificate with the following command

   `openssl x509 -in server.csr -out server.cert -req -signkey server.key -days 365

8. Delete the server.csr file from the apache\bin folder.

9. Copy the server.key and server.cert files from the apache\bin folder to the apache\conf folder.

10. Open apache\conf\httpd.conf in a text editor.

11. Change the listen port directive (which will probably either be Listen 80 or Listen 8080) to port 443:

    Listen 443

12. Change the ServerName directive to include port 443 (note this may be commented out so remove the # at the start of the line if it is and replace server with your server name):

    ServerName server:443

13. Uncomment or add the load module directive for mod_ssl (this should be present and commented so remove the # at the start of the line):

    LoadModule ssl_module modules/mod_ssl.so

14. Add an IfModule section for mod_ssl (this shouldn't already be there, but if it is overwrite it):

    <IfModule mod_ssl.c>
        SSLEngine on
        SSLRandomSeed startup   builtin
        SSLRandomSeed connect   builtin
        SSLPassPhraseDialog     builtin
        SSLSessionCache         dbm:logs/ssl_scache
        SSLSessionCacheTimeout  300
        SSLMutex                default
        SSLCertificateFile      conf\server.cert
        SSLCertificateKeyFile   conf\server.key
    </IfModule>

15. Restart the Apache service. Test configuration by attempting (and failing) to connect via http, and attempting (and succeeding) to connect via https.

Well, since the user Jure1873 hasn't written up an answer, I cannot give him the credit deserved. Here is his solution:

what if you replace <VirtualHost mail.craimer.org:443> with <virtualhost *:443>?

And that was the solution. It turns out that (as of this writing) httpd cannot support multiple virtual hosts for HTTPS, so any connections to 443 must be directed to a single host. So I guess httpd was just silently rejecting the configuration that attempting to run a virtual host for HTTPS.

Oh, and don't rail against apache for this "missing feature". It's not their fault! The HTTPS protocol doesn't support virtual hosts.

Boring Explaination:

You see, when you connect to port 443, and start an HTTPS session, all that's happening is security negotiation. HTTPS is all about setting up a secure tunnel between two points, and has nothing to do with HTTP. Only once the tunnel is set up, will data flow through. That data is the HTTP stream.

This means that the Host: directive (which is part of HTTP, not HTTPS) will only get sent after the secure tunnel has been constructed. It is the Host: header which tells HTTP server which virtual host is being accessed. But in HTTPS, we get this information far too late: it arrives after we had to choose encryption keys.

Bottom line: HTTPS cannot choose encryption keys based on the HTTP hostname.

Remove the tag from the VirtualHost configuration. EG. <IfModule mod_ssl.c > </IfModule> - remove those lines

Here is one more situation in which this error occurs:

Define VirtualHost *:80 in sites-enabled/000-default.conf. Then define VirtualHost *:443

in httpd.conf

If you move the configuration completely to either httpd.conf or to 000-default.conf it works. Else you get this error on FireFox:

SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)

and this error on chrome:

This site can’t provide a secure connection
... sent an invalid response.

Scraimer, the accepted answer is wrong, otherwise why do you think SSLCertificateFile directive can be in virtual host scope? Proof: http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatefile

With virtual hosts, you still can use different cert files with name based virtual hosts.

I had the same trouble and the solution was to put real IP instead of * in VirtualHost directive, like this:

NameVirtualHost *:80
NameVirtualHost *:443

<VirtualHost 127.0.0.1:443>
  ServerName affx.meg
  ...
</VirtualHost>

P.S. Hovewer I do not know why it worked. I just took this configuration as an example from real live server and reused it to my setup and it worked.