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.

Apache 2.2.3/mod_ssl/CentOS 5.5 VPS

Our certificate expired on 2011-10-06, and even though we have seemingly installed the new one correctly, browsing to the site still shows an expired certificate! I've tried deleting my browser cache and using several different browsers. Relevant lines from the ssl.conf file (I've excluded those commented out.):

Listen 127.0.0.1:443
SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
# Note - I tried disabling SSLSessionCache with the "none" setting but it didn't help.
<VirtualHost 127.0.0.1:443>
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.crt
SSLCertificateKeyFile /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.key
SSLCertificateChainFile /var/certs/gentlemanjoe.com/new2011/gd_bundle.crt
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"
ServerAdmin webmaster@donotemailme.com
DocumentRoot /var/www/gentlemanjoe.com
ServerName gentlemanjoe.com
<Directory /var/www/gentlemanjoe.com>
    AllowOverride All
    Order deny,allow
    allow from all
</Directory>          
</VirtualHost>

Things I've Checked

First I tried moving the old cert and key files to a completely different folder to make sure Apache wasn't still grabbing them somehow. Nothing changed. For fun I tried temporarily renaming the new cert and key files, and Apache dutifully complained and refused to start.

Then I tried to make sure I wasn't being fooled by editing the wrong config file. Using "locate" I found only one httpd.conf file under /etc/httpd/conf/httpd.conf. I also used "locate" to verify that there is only one ssl.conf file, /etc/httpd/conf.d/ssl.conf. The key file is what I generated using OpenSSL, following the instructions GoDaddy gave for generating the CSR.

I have verified that I am working with the right site by uploading a test.html file to the /var/www/gentlemanjoe.com folder and verifying that I can browse to it. But if I try to view the test file in HTTPS, I get the same certificate expiration warning.

I verified that the cert itself has the right expiration date:

openssl x509 -in /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.crt -noout -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            07:e7:49:69:97:96:16
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification Authority/serialNumber=07969287
        Validity
            Not Before: Oct 21 17:37:55 2011 GMT
            Not After : Oct  8 21:16:03 2013 GMT
        Subject: C=CA, ST=BC, L=Burnaby, O=Diamond Bailey Consolidated Commercial Services Ltd, OU= , CN=www.gentlemanjoe.com

I tried re-keying the cert at GoDaddy with a new CSR and everything seems to work, but I get the same result in the browser.

Possible Clue #1

Whenever I do "apachectl restart", I see this in the error_log file:

[Fri Oct 21 18:03:33 2011] [notice] SIGHUP received.  Attempting to restart
[Fri Oct 21 18:03:33 2011] [notice] Digest: generating secret for digest authentication ...
[Fri Oct 21 18:03:33 2011] [notice] Digest: done
[Fri Oct 21 18:03:33 2011] [info] APR LDAP: Built with OpenLDAP LDAP SDK
[Fri Oct 21 18:03:33 2011] [info] LDAP: SSL support available
[Fri Oct 21 18:03:33 2011] [info] Init: Seeding PRNG with 256 bytes of entropy
[Fri Oct 21 18:03:33 2011] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Fri Oct 21 18:03:33 2011] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Fri Oct 21 18:03:33 2011] [info] Shared memory session cache initialised
[Fri Oct 21 18:03:33 2011] [info] Init: Initializing (virtual) servers for SSL
[Fri Oct 21 18:03:33 2011] [warn] RSA server certificate CommonName (CN) `www.gentlemanjoe.com' does NOT match server name!?
[Fri Oct 21 18:03:33 2011] [info] Server: Apache/2.2.3, Interface: mod_ssl/2.2.3, Library: OpenSSL/0.9.8e-fips-rhel5
[Fri Oct 21 18:03:34 2011] [notice] Apache/2.2.3 (CentOS) configured -- resuming normal operations
[Fri Oct 21 18:03:34 2011] [info] Server built: Aug 30 2010 12:28:40

The GoDaddy techs tell me that the www vs non-www should not matter, and I tend to agree, since the security warning in my browser is not complaining about a server name mismatch, but rather an expiration, indicating that the old certificate is still being loaded somehow.

Possible Clue #2

The HTTP Server response header for http://gentlemanjoe.com says "Andromeda" rather than "Apache". This seems weird to me since my Googling of "Andromeda" turns up a media-server type project, which wouldn't be installed on this server (but I can't say that with certainty since I didn't set any of this up, the usual admin/developer is on holiday and I'm just helping a friend with his site.) Also, the httpd.conf file does not contain the string "Andromeda" indicating that it hasn't been modified to spit this out. So it might be the Magento e-commerce platform he's using, but what would be the point of replacing the standard Apache response header?

share|improve this question
    
What is this error: RSA server certificate CommonName (CN) `www.gentlemanjoe.com' does NOT match server name!? –  mdpc Oct 21 '11 at 23:54
    
I'm not really sure, I think it's complaining that www.gentlemanjoe.com does not match gentlemanjoe.com, but that does not explain why the site is still using an expired certificate. If it was only a common name/server name mistmatch error, wouldn't I see that reflected in the browser security warning? The new certificate shouldn't show up as expired, but with a different warning about the name mistmatch, right? –  Jordan Rieger Oct 21 '11 at 23:58
add comment

1 Answer

up vote 8 down vote accepted

Something's in front of Apache. Check out that config:

Listen 127.0.0.1:443
....
<VirtualHost 127.0.0.1:443>

It's listening on localhost only, so internet clients aren't hitting this service directly - they're likely getting proxied.

For the sanity check that Apache's loading the right cert, hit the service directly on Apache's listener: openssl s_client -connect 127.0.0.1:443 -showcerts

Not sure about the Andromeda header, so, let's find the process: lsof -i.

Apache will have 127.0.0.1:443, while some other service has 0.0.0.0:443 (or the VPS's public address :443) - that's the one that needs the new cert.

share|improve this answer
    
Yes! Thank you Shane, that was very logical. Boy this was a tough one. The process turned out to be a proxy server called nginx, listening on an IP address that I didn't even know was associated with the server and then relaying HTTPS and HTTP requests to Apache. I have no clue why the last guy thought this was a good idea, it seems to be a pointless performance hog. And nginx required me to reformat the certificates that GoDaddy provided to put the server cert and the authority chain in one file in a certain order. Anyways, it works now! Thank you! –  Jordan Rieger Oct 22 '11 at 6:53
    
@JordanRieger Good to hear! nginx is generally considered to be lighter and faster than Apache, so there could be a case for it if it's handling some requests internally (say, the static content) and passing only a specific subset of requests to Apache.. but it sounds like it's just sending everything to Apache, so you're right - just a performance waste. –  Shane Madden Oct 22 '11 at 18:25
add comment

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.