Sertifika yetkilisi kök sertifika süresinin dolması ve yenilenmesi

2004'te, Linux'ta OpenSSL ve OpenVPN ile birlikte verilen basit yönetim komut dosyalarını kullanarak küçük bir sertifika yetkilisi kurdum. O zaman bulduğum rehberlere göre, kök CA sertifikasının geçerlilik süresini 10 yıl olarak belirledim. O zamandan beri, OpenVPN tünelleri, web siteleri ve e-posta sunucuları için hepsi de 10 yıllık bir geçerlilik süresine sahip pek çok sertifika imzaladım (bu yanlış olabilir, ama o zamanlar daha iyi bilmiyordum).

Bir CA kurma konusunda birçok rehber buldum, ancak yönetimi hakkında ve özellikle de, kök CA sertifikasının süresi dolduğunda yapılması gerekenler hakkında, 2014'te bir süre gerçekleşecek olan hakkında çok az bilgi buldum. sorular:

• Kök CA sertifikasının süresi dolduktan sonra geçerlilik süresi uzayan sertifikalar, geçerlilik süresinin sona ermesiyle geçersiz sayılacak mı veya geçerli olmaya devam edecekler mi (CA sertifikasının geçerlilik süresi içinde imzalandıkları için)?
• Kök CA sertifikasını yenilemek ve süresinin dolması sırasında sorunsuz bir geçiş sağlamak için hangi işlemler gereklidir?
  • Mevcut kök CA sertifikasını farklı bir geçerlilik süresiyle yeniden imzalayabilir ve yeni imzalanan sertifikayı istemcilere yükleyebilir miyim, böylece müşteri sertifikaları geçerli kalır?
  • Yoksa tüm müşteri sertifikalarını yeni bir kök CA sertifikası ile imzalanmış olanlarla mı değiştirmeliyim?
• Kök CA sertifikası ne zaman yenilenmelidir? Son kullanma tarihine yakın mı yoksa son kullanma tarihinden önce makul bir süre mi?
• Kök CA sertifikasının yenilenmesi önemli bir iş parçası haline gelirse, bir sonraki yenilemede daha yumuşak bir geçiş sağlamak için şimdi daha iyi ne yapabilirim (geçerlilik süresinin 100 yıla ayarlanması elbette)?

Bu durum, bazı müşterilere tek erişimimin mevcut CA sertifikası tarafından imzalanan bir sertifikayı kullanan bir OpenVPN tüneli üzerinden olması nedeniyle biraz daha karmaşık hale geliyor, bu nedenle tüm müşteri sertifikalarını değiştirmek zorunda kalırsam kopyalamam gerekecek müşteriye yeni dosyalar, tüneli yeniden başlatın, parmaklarımı çaprazlayın ve sonradan ortaya çıkacağını umuyorum.

Kök CA'nızda aynı özel anahtarı saklamak, tüm sertifikaların yeni köke karşı başarıyla doğrulamaya devam etmesini sağlar; Senden tek istediğin, yeni köke güvenmek.

Sertifika imzalama ilişkisi özel anahtardan bir imzaya dayanır; Yeni bir kamu sertifikası oluştururken aynı özel anahtarı (ve dolaylı olarak aynı açık anahtarı) saklamak, yeni bir geçerlilik süresi ve gerektiğinde değiştirilen diğer yeni nitelikler ile güven ilişkisini sürdürmek. CRL'ler, eski sertifikadan yeniye, özel anahtarla imzalanmış sertifikalar gibi devam edebilirler.

Öyleyse doğrulayalım!

Kök CA yap:

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

Ondan bir alt sertifika oluşturun:

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

Çocuk sertifikasını imzala:

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

Hepsi orada, normal sertifika ilişkisi var. Güvenini doğrulayalım:

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

Tamam, şimdi 10 yıl geçti diyelim. Aynı kök özel anahtardan yeni bir genel sertifika oluşturalım.

openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

Ve .. işe yaradı mı?

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

Ama neden? Onlar farklı dosyalar değil mi?

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

Evet, ancak bu, yeni ortak anahtarın kriptografik olarak sertifikadaki imzayla eşleşmediği anlamına gelmez. Farklı seri numaraları, aynı modül:

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

Gerçek dünya sertifika doğrulamasında çalıştığını doğrulamak için biraz daha ileri gidelim.

Bir Apache örneğini ateşleyin ve hadi gidelim (debian dosya yapısı, gerektiği gibi ayarlayın):

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

Bu direktifleri VirtualHost443 no'lu bir dinlemeye koyacağız - unutmayın, newroot.pemkök sertifika cert.pemoluşturulup imzalandığında bile yoktu .

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

Openssl'ın nasıl gördüğünü kontrol edelim:

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

Tamam, peki ya MS’in kripto API'sini kullanan bir tarayıcı? Köke güvenmelisin, önce yeni kökün seri numarasıyla, sonra her şey yolunda.

Ve hala eski kökünle çalışmalıyız. Apache'nin yapılandırmasını şu şekilde değiştirin:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

Apache'de tamamen yeniden başlatıldığında, yeniden yükleme işlemi cerları düzgün bir şekilde değiştirmez.

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

Ve MS şifreleme API tarayıcısıyla Apache eski kökü sunuyor, ancak yeni kök hala bilgisayarın güvenilir kök deposunda. Apache'nin farklı bir zincir (eski kök) sunmasına rağmen otomatik olarak onu bulur ve güvenilir (yeni) köke karşı o sertifikayı doğrular. Yeni kökü güvenilir köklerden çıkardıktan ve orijinal kök sertifikasını ekledikten sonra her şey yolunda:

Demek bu kadar! Yenilediğinizde, yeni güvenilir kökünden geçerken aynı özel anahtarı saklayın ve hemen hemen hepsi işe yarar . İyi şanslar!

Orijinal CA anahtarının yenilenen sertifikasında CA uzantılarının eksik olabileceğini fark ettim. Bu benim için daha uygun bir şekilde çalıştı ( v3 CA uzantılarının tanımlandığı bir ./renewedselfsignedca.conf oluşturur ve ca.key ve ca.crt dosyasının orijinal CA anahtarı ve sertifikası olduğu varsayılır):

openssl x509 -x509toreq -in ca.crt -signkey ca.key -out renewedselfsignedca.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > renewedselfsignedca.conf
openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey ca.key -out renewedselfsignedca.crt -extfile ./renewedselfsignedca.conf -extensions v3_ca

Geçerli kök süresini uzatmak için temel mod (X.509 ve ortak özel anahtara ihtiyacınız var):

CSR'yi genel X.509 ve özel anahtardan oluşturun:

openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr

CSR'yi özel anahtarla yeniden imzalayın:

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

@Bianconiglio plus -set_serial benim için çalıştı. Sunucum yalnızca intranettir, bu yüzden yan etkilerin ne olduğu konusunda endişelenmiyorum ve artık "uygun" bir çözüm üzerinde çalışmak için zamanım var.

Aşağıdaki yapılandırılabilir betiği kullandım. Sadece CACRT, CAKEY ve NEWCA değişkenlerini ayarlayın.

# WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout

Kök sertifikanızın süresi dolduğunda, imzaladığınız sertifikaları da kullanın. Yeni bir kök sertifikası oluşturmanız ve onunla yeni sertifikalar imzalamanız gerekir. İşlemi birkaç yılda bir tekrarlamak istemiyorsanız, tek gerçek seçenek kök sertifikasının geçerli tarihini on ya da yirmi yıl gibi uzatmaktır: Kendi kullanımım için oluşturduğum kök Yirmi yıl verdim.

Bir kök sertifikasını "yenileyemezsin". Tek yapabileceğiniz yeni bir tane oluşturmak.

Eskisinin kullanım süresi sona ermeden en az bir veya iki yıl önce yeni bir kök oluşturun, böylece bir şeyler ters giderse zaman duvarına çarpmadan geçme zamanınız olur. Bu yolla, yeni sorunla ilgili sorun yaşamadan her zaman geçici olarak eski cerlara geri dönebilirsiniz.

VPN tünelleri açıldığında, denemek için birkaç testbed sunucu kurardım, böylece bir müşterinin makinesi ile yapmadan önce ne yapmanız gerektiğini tam olarak anlarsınız.

Aynı sorunu yaşadık ve bu durum bizim durumumuzda idi çünkü Debian sunucusu güncel değildi ve openSSL'de şu sorun vardı:

https://en.wikipedia.org/wiki/Year_2038_problem

Debian 6 için mevcut olan OpenSSL'in son sürümü bu sorunu getiriyor. 23.01.2018 tarihinden sonra oluşturulan tüm sertifikalar bir Vality üretir: 1901 yıl!

Çözüm, OpenSSL'yi güncellemektir. İstemciler için yeniden yapılandırma dosyalarını (sertifikalarla birlikte) oluşturabilirsiniz.