Apache tampaknya menggunakan sertifikat kadaluarsa lama meskipun yang baru diinstal


15

Apache 2.2.3 / mod_ssl / CentOS 5.5 VPS

Sertifikat kami kedaluwarsa pada 2011-10-06, dan meskipun kami tampaknya telah menginstal yang baru dengan benar, menjelajah ke situs masih menunjukkan sertifikat yang kedaluwarsa! Saya sudah mencoba menghapus cache browser saya dan menggunakan beberapa browser yang berbeda. Baris yang relevan dari file ssl.conf (Saya sudah mengecualikan yang berkomentar.):

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>

Hal-hal yang Sudah Saya Periksa

Pertama saya mencoba memindahkan file sertifikat dan kunci lama ke folder yang sama sekali berbeda untuk memastikan Apache tidak mengambilnya. Tidak ada yang berubah. Untuk bersenang-senang saya mencoba mengubah nama sementara sertifikat baru dan file-file kunci, dan Apache dengan patuh mengeluh dan menolak untuk memulai.

Kemudian saya mencoba memastikan saya tidak tertipu dengan mengedit file konfigurasi yang salah. Menggunakan "temukan", saya hanya menemukan satu file httpd.conf di bawah /etc/httpd/conf/httpd.conf. Saya juga menggunakan "temukan" untuk memverifikasi bahwa hanya ada satu file ssl.conf, /etc/httpd/conf.d/ssl.conf. File kuncinya adalah apa yang saya hasilkan menggunakan OpenSSL, mengikuti instruksi yang diberikan GoDaddy untuk menghasilkan CSR.

Saya telah memverifikasi bahwa saya bekerja dengan situs yang tepat dengan mengunggah file test.html ke folder /var/www/gentlemanjoe.com dan memverifikasi bahwa saya dapat menjelajahinya. Tetapi jika saya mencoba untuk melihat file uji di HTTPS, saya mendapatkan peringatan kedaluwarsa sertifikat yang sama.

Saya memverifikasi bahwa sertifikat itu sendiri memiliki tanggal kedaluwarsa yang tepat:

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

Saya mencoba memasukkan kembali sertifikat di GoDaddy dengan CSR baru dan semuanya tampaknya berfungsi, tetapi saya mendapatkan hasil yang sama di browser.

Kemungkinan Petunjuk # 1

Setiap kali saya melakukan "apachectl restart", saya melihat ini di file error_log:

[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

Teknisi GoDaddy memberi tahu saya bahwa www vs non-www seharusnya tidak menjadi masalah, dan saya cenderung setuju, karena peringatan keamanan di browser saya tidak mengeluh tentang ketidakcocokan nama server, melainkan kedaluwarsa , menunjukkan bahwa sertifikat lama masih sedang dimuat entah bagaimana.

Kemungkinan Petunjuk # 2

Header respons HTTP Server untuk http://gentlemanjoe.com mengatakan "Andromeda" daripada "Apache". Ini terasa aneh bagi saya karena Googling saya dari "Andromeda" muncul jenis proyek media-server, yang tidak akan diinstal pada server ini (tapi saya tidak bisa mengatakan itu dengan pasti karena saya tidak mengatur semua ini , admin / pengembang yang biasa sedang berlibur dan saya hanya membantu seorang teman dengan situsnya.) Juga, file httpd.conf tidak mengandung string "Andromeda" yang menunjukkan bahwa itu belum dimodifikasi untuk meludahkan ini. Jadi itu mungkin platform e-commerce Magento yang dia gunakan, tetapi apa gunanya mengganti header respons standar Apache?


Apa kesalahan ini: Sertifikat server RSA CommonName (CN) `www.gentlemanjoe.com 'TIDAK cocok dengan nama server !?
mdpc

Saya tidak begitu yakin, saya pikir itu mengeluh bahwa www.gentlemanjoe.com tidak cocok dengan gentlemanjoe.com, tetapi itu tidak menjelaskan mengapa situs ini masih menggunakan sertifikat yang kadaluwarsa. Jika itu hanya kesalahan nama umum / nama server mistmatch, tidakkah saya melihat hal itu tercermin dalam peringatan keamanan browser? Sertifikat baru seharusnya tidak muncul sebagai kedaluwarsa , tetapi dengan peringatan berbeda tentang kesalahan nama, kan?
Jordan Rieger

Jawaban:


17

Ada sesuatu di depan Apache. Lihat konfigurasi itu:

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

Ini mendengarkan di localhost saja, sehingga klien internet tidak langsung menyentuh layanan ini - mereka kemungkinan mendapatkan proksi.

Untuk memeriksa kewarasan bahwa Apache memuat sertifikat yang tepat, langsung tekan layanan pada pendengar Apache: openssl s_client -connect 127.0.0.1:443 -showcerts

Tidak yakin tentang header Andromeda, jadi, mari kita menemukan proses: lsof -i.

Apache akan memiliki 127.0.0.1:443, sementara beberapa layanan lain memiliki 0.0.0.0:443(atau alamat publik VPS :443) - itulah yang membutuhkan sertifikat baru.


Iya! Terima kasih, Shane, itu sangat logis. Bocah ini tangguh. Prosesnya ternyata adalah server proxy yang disebut nginx, mendengarkan pada alamat IP yang bahkan tidak saya ketahui dikaitkan dengan server dan kemudian menyampaikan permintaan HTTPS dan HTTP ke Apache. Saya tidak tahu mengapa orang terakhir berpikir ini adalah ide yang bagus, tampaknya menjadi babi yang tidak berguna. Dan nginx mengharuskan saya untuk memformat ulang sertifikat yang disediakan GoDaddy untuk meletakkan sertifikat server dan rantai otoritas dalam satu file dalam urutan tertentu. Bagaimanapun, itu bekerja sekarang! Terima kasih!
Jordan Rieger

2
@JordanRieger Senang mendengar! nginx umumnya dianggap lebih ringan dan lebih cepat dari Apache, jadi mungkin ada kasus untuk itu jika menangani beberapa permintaan secara internal (katakanlah, konten statis) dan hanya mengirimkan sebagian permintaan tertentu ke Apache .. tetapi sepertinya itu adalah hanya mengirim semuanya ke Apache, jadi Anda benar - hanya pemborosan kinerja.
Shane Madden

Dalam kasus kami, itu AWS ELB.
Akshay

0

Sumber umum masalah ini adalah beberapa instance Apache yang berjalan. Perubahan konfigurasi diambil oleh proses yang Anda mulai kembali tetapi permintaan dilayani oleh proses lama yang berjalan dengan konfigurasi lama.

Hentikan layanan:

service apache2 stop

Periksa apakah situs tersebut masih dapat diakses. Jika ya, maka Anda telah mengidentifikasi penyebabnya.

Sekarang jalankan

ps aux | grep apache

Ini akan memberi Anda daftar menjalankan proses apache2 dan PID mereka. Bunuh mereka semua (Catatan, perintah ini juga dapat mengembalikan proses yang tidak terkait dengan Apache dalam nama / pengguna mereka dll. Seperti Apache Tomcat, Anda mungkin tidak ingin membunuh mereka.)

kill <pid>

Jalankan ps aux lagi dan pastikan proses tidak lagi berjalan.

Periksa lagi apakah situs dapat diakses. Seharusnya tidak.

Sekarang mulai layanan apache

service apache2 start

Verifikasi bahwa sertifikat baru sedang dilayani.

Jika Anda tidak ingin mematikan proses, Anda dapat mem-boot ulang sistem. Ini akan memiliki efek yang sama.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.