Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm trying to set up HTTPS on Apache, using a self-signed certificate. But instead of displaying the page, I get a bunch of weird errors. An a different error from each browser!

From Chrome:

Error 2 (net::ERR_FAILED): Unknown error.

From Firefox:

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

I followed the steps detailed on http://slacksite.com/apache/certificate.php, as well as about 4 other guides. They are all about the same, but all give the same result. So I must be doing something wrong.

Briefly, here's what I did:

  • Generate the server key:

    openssl genrsa -des3 -out server.key 1024

  • Generate CSR:

    openssl req -new -key server.key -out server.csr

[while generating the request, I was careful to enter my actual hostname as the "Common Name (eg, your name or your server's hostname)"]

  • remove password from key:

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

  • Self-sign the certificate:

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

  • Configured apache to point at those files, and use those certificates.

Any ideas?

UPDATE: Here's my virtual host configuration:

LoadModule ssl_module modules/mod_ssl.so
Listen 443
#   Some MIME-types for downloading Certificates and CRLs
#
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl
SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
SSLMutex default
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin

## Virtual host to redirect to HTTPS
<VirtualHost *:80>
    ServerName mail.craimer.org
    Redirect permanent / https://mail.craimer.org:443
</VirtualHost>

##
## SSL Virtual Host Context
##

<VirtualHost mail.craimer.org:443>
    ServerName mail.craimer.org
    DocumentRoot "/usr/share/roundcubemail/trunk/roundcubemail/"

         ErrorLog logs/ssl_error_log
         TransferLog logs/ssl_access_log
         LogLevel warn

         SSLEngine on

         SSLProtocol all -SSLv2

         SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

         SSLCertificateFile /etc/httpd/conf/ssl/server.crt
         SSLCertificateKeyFile /etc/httpd/conf/ssl/server.key

         <Files ~ "\.(cgi|shtml|phtml|php3?)$">
                                SSLOptions +StdEnvVars
         </Files>
         <Directory "/var/www/cgi-bin">
                                SSLOptions +StdEnvVars
         </Directory>

    # Deal with broken MSIE
         SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

    CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
share|improve this question

migrated from superuser.com Jul 21 '09 at 11:07

This question came from our site for computer enthusiasts and power users.

    
Are you using the default SSL port? If not, are you putting the new port in the URL? –  JP Alioto Jul 21 '09 at 5:31
    
Could you paste you apache/vhost configuration? –  Marie Fischer Jul 21 '09 at 12:51
    
Was this solved? What was the solution? –  David Rabinowitz Dec 9 '10 at 8:49

5 Answers 5

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.

share|improve this answer
    
All I'm doing is typing in "mail.craimer.org"; into my web browser. You'd think that would work, no? –  scraimer Jul 22 '09 at 14:55
    
ugh. it mulched the url. it was https : // mail.craimer.org –  scraimer Jul 22 '09 at 14:56
2  
what if you replace <VirtualHost mail.craimer.org:443> with <virtualhost *:443>? –  Jure1873 Jul 22 '09 at 21:48
    
@Jure1873 Wow! That worked! - write is up as an answer, and I'll make it the accepted one, k? –  scraimer Jul 23 '09 at 11:33
    
The likely reason is that it was being caught by a <VirtualHost *> directive further up the chain/config. –  Dan Carley Jul 23 '09 at 11:37

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.

share|improve this answer

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

share|improve this answer
    
Didn't have those in my config... –  scraimer Jul 22 '09 at 14:50
up vote 0 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.