Apache, yenisi yüklü olsa bile eski süresi dolmuş sertifikayı kullanıyor gibi görünüyor


15

Apache 2.2.3 / mod_ssl / CentOS 5.5 VPS

Sertifikamızın süresi 2011-10-06'da dolmuştu ve yenisini doğru bir şekilde yüklemiş olsak da , siteye göz atmak hala süresi dolmuş bir sertifika gösteriyor! Tarayıcı önbelleğimi silmeyi ve birkaç farklı tarayıcı kullanmayı denedim. Ssl.conf dosyasından ilgili satırlar (bu açıklamaları hariç tuttum.):

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>

Kontrol Ettiğim Şeyler

İlk önce Apache'nin onları bir şekilde yakalamadığından emin olmak için eski sertifikayı ve anahtar dosyalarını tamamen farklı bir klasöre taşımayı denedim. Hiçbirşey değişmedi. Eğlenmek için geçici olarak yeni sertifika ve anahtar dosyaları yeniden adlandırmayı denedim ve Apache şiddetle şikayet etmeyi ve başlamayı reddetti.

Sonra yanlış yapılandırma dosyasını düzenleyerek aldanmamayı sağlamaya çalıştım. "Locate" kullanarak /etc/httpd/conf/httpd.conf altında yalnızca bir httpd.conf dosyası buldum. Ayrıca, yalnızca bir ssl.conf dosyası olan /etc/httpd/conf.d/ssl.conf olduğunu doğrulamak için "locate" komutunu kullandım. Anahtar dosya, GoDaddy'nin CSR oluşturmak için verdiği talimatları izleyerek OpenSSL kullanarak oluşturduğum şey.

/Var/www/gentlemanjoe.com klasörüne bir test.html dosyası yükleyip bu dosyaya göz atabildiğimi doğrulayarak doğru siteyle çalıştığımı doğruladım. Ancak, test dosyasını HTTPS'de görüntülemeye çalışırsam, aynı sertifika sona erme uyarısını alırım.

Sertifikanın kendisinin doğru son kullanma tarihine sahip olduğunu doğruladım:

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

GoDaddy'deki sertifikayı yeni bir CSR ile yeniden girmeyi denedim ve her şey işe yarıyor gibi görünüyor, ancak tarayıcıda aynı sonucu alıyorum.

Olası İpucu # 1

Ne zaman "apachectl restart" yapmak, bunu error_log dosyasında görüyorum:

[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

GoDaddy teknikleri bana www-www olmayanların önemli olmaması gerektiğini söylüyor ve kabul ediyorum, çünkü tarayıcımdaki güvenlik uyarısı bir sunucu adı uyuşmazlığından şikayet etmiyor , aksine eski sertifikanın hala devam ettiğini gösteren bir süre sonu bir şekilde yükleniyor.

Olası İpucu # 2

HTTP Sunucusu yanıt başlığını http://gentlemanjoe.com ziyade "Apache" den "Andromeda" diyor. "Andromeda" adlı Google çalışanım bu sunucuya yüklenmeyecek bir medya sunucusu türü projeyi ortaya çıkardığı için bu bana garip geliyor (ama bunu kesin olarak ayarlayamadığım için bunu kesinlikle söyleyemem , her zamanki yönetici / geliştirici tatilde ve ben sadece onun arkadaşı ile bir site yardım ediyorum.) Ayrıca, httpd.conf dosya "tükürmek için değiştirilmedi olmadığını belirten" Andromeda "dizesini içermiyor. Bu yüzden kullandığı Magento e-ticaret platformu olabilir, ancak standart Apache yanıt başlığını değiştirmenin anlamı ne olurdu?


Bu hata nedir: RSA sunucu sertifikası CommonName (CN) `` www.gentlemanjoe.com '' sunucu adıyla eşleşmiyor !?
mdpc

Pek emin, ben değilim düşünüyorum o www.gentlemanjoe.com gentlemanjoe.com uyuşmadığını şikayetçi, ama site hala süresi dolmuş bir sertifika kullanıyor yüzden açıklamaz. Yalnızca ortak bir ad / sunucu adı yanlış eşleme hatası olsaydı, bunun tarayıcı güvenlik uyarısına yansıdığını görmez miydim? Yeni sertifikanın süresi dolmuş olarak görünmemeli , ancak yanlış eşleşme adı hakkında farklı bir uyarı ile değil mi?
Jordan Rieger

Yanıtlar:


17

Apache'nin önünde bir şey var. Şu yapılandırmaya göz atın:

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

Yalnızca localhost üzerinde dinliyor, bu nedenle internet istemcileri bu hizmete doğrudan çarpmıyor - muhtemelen proxy yapıyorlar.

Akıl sağlığı için, Apache'nin doğru sertifikayı yüklediğini kontrol edin, doğrudan Apache'nin dinleyicisine servis yapın: openssl s_client -connect 127.0.0.1:443 -showcerts

Emin değilim Andromeda başlığındaki hakkında, bu yüzden, en sürecini bulalım: lsof -i.

Apache'nin sahip 127.0.0.1:443olduğu diğer bazı hizmetlerin 0.0.0.0:443(veya VPS'nin genel adresini :443) varken - bu yeni sertifikaya ihtiyaç duyan kişidir.


Evet! Teşekkürler Shane, bu çok mantıklıydı. Çocuk bu zor biriydi. Süreç bile biliyorum o zaman sunucu ile ilişkili olduğu ve olmadığı bir IP adresini dinleyen, nginx adında bir proxy sunucusu olduğu ortaya çıktı geçişini Apache HTTPS ve HTTP istekleri. Son adamın bunun neden iyi bir fikir olduğunu düşündüğü hakkında hiçbir fikrim yok, anlamsız bir performans domuzu gibi görünüyor. Ve nginx, GoDaddy'nin sunucu sertifikasını ve yetki zincirini belirli bir sırada bir dosyaya koymak için sağladığı sertifikaları yeniden biçimlendirmemi istedi. Her neyse, şimdi çalışıyor! Teşekkür ederim!
Jordan Rieger

2
@JordanRieger Duymak güzel! nginx genellikle Apache'den daha hafif ve daha hızlı olarak kabul edilir, bu nedenle bazı istekleri dahili olarak (örneğin, statik içerik) işliyor ve yalnızca belirli bir istek alt kümesini Apache'ye geçiriyorsa bir durum olabilir. her şeyi Apache'ye gönderiyoruz, bu yüzden haklısınız - sadece performans kaybı.
Shane Madden

Bizim durumumuzda AWS ELB idi.
Akshay

1

Bu sorunun yaygın bir kaynağı, birden çok çalışan Apache örneğidir. Yapılandırma değişiklikleri (yeniden) başlattığınız bir işlem tarafından alınır, ancak istek eski yapılandırmayla çalışan eski bir işlem tarafından sunulur.

Hizmeti durdurun:

service apache2 stop

Sitenin hala erişilebilir olup olmadığını kontrol edin. Evet ise, nedeni belirlediniz.

Şimdi koş

ps aux | grep apache

Size çalışan apache2 işlemi ve PID'lerinin listesini verecektir. Hepsini öldür (Not, bu komut, Apache Tomcat gibi Apache ile adlarında / kullanıcısında vb. İlgisiz işlemleri de döndürebilir, onları öldürmek istemeyebilirsiniz.)

kill <pid>

Ps aux'u tekrar çalıştırın ve işlemlerin artık çalışmadığından emin olun.

Sitenin erişilebilir olup olmadığını tekrar kontrol edin. Olmamalı.

Şimdi apache servisini başlatın

service apache2 start

Yeni sertifikanın sunulduğunu doğrulayın.

İşlemleri öldürmek istemiyorsanız, sistemi yeniden başlatabilirsiniz. Aynı etkiye sahip olacaktır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.