Soru Sertifika yetkilisi kök sertifikası süresinin dolması ve yenilenmesi


2004 yılında, Linux'ta OpenSSL ve OpenVPN ile sağlanan basit yönetim betiklerini kullanarak küçük bir sertifika yetkilisi kurdum. O sırada bulduğum kılavuzlara göre, kök CA sertifikası için geçerlilik süresini 10 yıla ayarlıyorum. O zamandan beri, OpenVPN tünelleri, web siteleri ve e-posta sunucuları için, 10 yıllık bir geçerlilik süresi olan çok sayıda sertifikayı imzaladım (bu yanlış olabilirdi, ancak o zamanlar daha iyi bilmiyordum).

Bir CA kurma konusunda birçok kılavuz buldum, ancak yönetimiyle ilgili çok az bilgi ve özellikle de kök CA sertifikasının süresi dolduğunda yapılması gerekenler hakkında 2014 yılında biraz zaman geçecek. Bu yüzden aşağıdakilere sahibim: sorular:

  • Kök CA sertifikasının sona ermesinden sonra geçerli bir geçerlilik süresi olan sertifikalar, ikincisinin geçerlilik süresi dolduğunda geçersiz olurlar veya geçerli olmaya devam ederler (CA sertifikasının geçerlilik süresi boyunca imzalandıkları için)?
  • Kök CA sertifikasını yenilemek ve sona erme tarihinde sorunsuz geçiş sağlamak için hangi işlemlere ihtiyaç duyulur?
    • Geçerli kök CA sertifikasını farklı bir geçerlilik süresiyle bir şekilde yeniden imzalayabilir ve yeni imzalı sertifikayı istemcilere gönderebilir, böylece istemci sertifikaları geçerliliğini koruyabilir mi?
    • Veya tüm istemci sertifikalarını yeni bir kök sertifika yetkilisi tarafından imzalanmış yenileriyle değiştirmem gerekiyor mu?
  • Kök CA sertifikası ne zaman yenilenmelidir? Son kullanma süresine veya sona ermeden önce makul bir süreye mi?
  • Kök CA sertifikasının yenilenmesi büyük bir iş parçası haline gelirse, bir sonraki yenileme işleminde daha sorunsuz bir geçiş sağlamak için şimdi daha iyi ne yapabilirim (geçerlilik süresini 100 yıl olarak belirleyemiyorum, tabii ki)?

Bazı müşterilere tek erişimimin şu anki CA sertifikası tarafından imzalanmış bir sertifikayı kullanan bir OpenVPN tünelinden geçmesiyle durum biraz daha karmaşık hale geliyor, bu yüzden tüm müşteri sertifikalarını değiştirmek zorunda kalırsam kopyalamam gerekecek. İstemciye yeni dosyalar, tüneli yeniden başlat, parmaklarımı geç ve sonradan gelmesini umarım.


87
2017-08-30 08:34


Menşei




Cevaplar:


Kök CA'nızda aynı özel anahtarı tutmak, tüm sertifikaların yeni köke karşı başarılı bir şekilde doğrulamaya devam etmesini sağlar; Senin için gereken her şey yeni köke güvenmek.

Sertifika imzalama ilişkisi, özel anahtarın imzasına dayanır; Yeni bir kamu sertifikası oluştururken aynı özel anahtarı (ve dolaylı olarak aynı ortak anahtarı) koruyarak, yeni bir geçerlilik süresi ve gerektiğinde değiştirilen diğer yeni özniteliklerle güven ilişkisini yerinde tutar. CRL'ler de, eski sertifikadan yeni sürüme, özel anahtar tarafından imzalanan sertifikalar gibi, devam edebilir.


Yani, hadi doğrulayalım!

Kök CA yap:

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

Ondan bir çocuk sertifikası oluştur:

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. Güveni 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 üretelim.

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 genel anahtarın sertifikadaki imzayı kriptografik olarak 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 geçerliliğinde çalıştığını doğrulamak için biraz daha ilerleyelim.

Bir Apache örneğini ateşleyin ve bir adım atalım (debian dosya yapısı, gerektiğinde 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 yönergeleri bir VirtualHost 443 dinlerken hatırlıyorum newroot.pem Kök sertifikası bile mevcut değildi cert.pem oluşturuldu ve imzalandı.

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

Openssl'in nasıl göründüğü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, ve MS'in şifreleme API'sini kullanan bir tarayıcıya ne dersiniz? Köküne güvenmelisin, önce her şey iyi, yeni kökü seri numarasıyla:

newroot

Ve hala eski kökle de çalışmalıyız. Apache'nin yapılandırmasını değiştir:

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

Apache üzerinde yeniden başlatma yapın, bir yeniden yükleme, uygun şekilde certs'leri değiştirmeyecektir.

# 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 kripto API tarayıcısı ile Apache eski kökü sunarken, 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 sertifikayı güvenilir (yeni) köke karşı doğrular. Yeni kökü güvenilen köklerden çıkardıktan ve orijinal kök sertifikasını ekledikten sonra, her şey yolunda:

oldroot


Yani, bu kadar! Yenilediğinizde aynı özel anahtarı koruyun, yeni güvenilen kökte değiştirin ve hemen hemen hepsi sadece çalışır. İyi şanslar!


124
2017-09-04 18:40



Her neyse, aynı özel anahtarı tekrar kullanacaksanız yeni bir kök sertifika oluşturmanın amacı nedir? Bunu tekrar tekrar yapmaya devam ederseniz, sertifika için bir son kullanma tarihine sahip olmanın anlamı nedir? Kökün sona ermesinin, anahtarları kırmaya çalışan ilerleyen makinelere karşı daha güvenli olan daha yeni (muhtemelen daha güçlü) bir özel anahtar oluşturmaya zorlamak için kullanıldığını düşünüyorum. 20 yıl önce yapılmış 40 bitlik bir anahtar, - jvhashe
@jvhashe Kök sertifikası artık kriptografik olarak yeterince güçlü değilse, son kullanma tarihinden bağımsız olarak ondan kurtulmanız gerekir. Kendi kökünüzü oluşturuyorsanız, gezegende artık olmayacağınız zaman yüzlerce yıllık bir geçmişe dayanmak için sizi durduran hiçbir şey kalmaz. Son kullanma, bir kök sertifikası ile neredeyse ilgili değildir ve bir çocuk sertifikası için son kullanma tarihi, kriptografik güçle ilgili değildir (Ekim ayında 1024 bitlik tüm sertifikaları iptal etmeye hazırlayan CA'lara sorun). İşte daha fazla bilgi için. - Shane Madden♦
Yukarıdakilere ek olarak, bu yöntemin çalışması için seri numarasının aynı olması gerektiğini buldum. - Scott Presnell
-set_serial 01 - O NE LAN??? SERİ NUMARALARI GERÇEĞİNİZ. Danıştınız mı RFC 4158, Internet X.509 Genel Anahtar Altyapısı: Sertifikasyon Yolu Oluşturma? Yoksa sen ilerledikçe mi yapıyorsun? Yol oluşturmaya başladıklarında kullanıcı aracılarına neden olduğunuz sorun hakkında hiçbir fikriniz yok. - jww
Cevabı okudun mu? Bu sadece kriptografinin çalıştığı gerçeğinin bir kanıtı. Bu komut, sadece eski ve yeni kök sertifika arasındaki ilişkiyi test etmek amacıyla, daha sonra doğrulayabileceğimiz bir test sertifikası üretiyor. Eğer birisi olduğu Bu komutları doğrudan kullanarak, kesinlikle bir şeylerin kırıldığını umarız ve kör bir şekilde çalıştırmadan önce bir şeyin içeriğine dikkat etmeleri gerektiğini fark ederler (ya da 01 Laboratuarda kabul edilebilir bir seridir). - Shane Madden♦


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ı (bir ./renewedselfsignedca.conf v3 CA uzantıları tanımlandığında ve ca.key ve ca.crt 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

13
2018-04-22 10:31



Bu son derece yararlı bir katkı oldu. Asıl geçerli cevabınız, orijinal kökünüzde isteğe bağlı ayarlarınız varsa, benim için yeterince uyumlu bir sertifikaya neden olmaz. - Theuni
İkincisi, çok yararlı. Başka bir ek: Scott Presnell gibi kabul edilen cevaba yapılan yorumlar gibi, yenilenen sertifikanın onaltılık seri numarasını da eski ile eşleştirecek şekilde manuel olarak belirtmem gerekiyordu. Bu ekleme anlamına geliyordu -set_serial 0xdeadbeefabba (x) gerçek x509 komutuna (gerçek seri no :) değil). Ancak daha sonra, istemci sertifikaları yenilenen CA sertifikasına karşı başarılı bir şekilde doğruladı. - JK Laiho
Bu yöntem, önceki bilgileri önceki sertifikaya göre daha kolay tutar. - lepe
Bu çözüm için bir komut dosyası oluşturdum artı -set_serial - cevabımı gör - Wolfgang Fahl
Bu cevap bana bir sürü iş kurtardı, neredeyse bir gün bunu gerektiren bir konuda geçirdikten sonra, neredeyse pes etmeyi başaracaktım, bu yüzden şapkamı sana bırakıyorum! - Onitlikesonic


Geçerli kök süresinin uzatılması için temel mod (public X.509'a ve ilişkilendirilmiş özel anahtara ihtiyacınız vardır):

Ortak X.509'dan ve özel anahtardan CSR'yi 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

2
2018-01-22 16:35





Kök sertifikanızın süresi dolduğunda, onunla imzaladığınız sertifikaları da yapın. Yeni bir kök sertifika oluşturup yeni sertifikaları imzalamanız gerekecek. İşlemi birkaç yılda bir tekrarlamak istemezseniz, asıl seçenek, on veya yirmi yıl gibi bir kök sertifikasındaki geçerli tarihi uzatmaktır: Kendi kullanımım için yarattığım kök 20 yıl önce belirledim.

Bir kök sertifikayı "yenileyemezsiniz". Tek yapabileceğiniz yeni bir tane oluşturmak.

Eski birinizin süresi dolmadan en az bir yıl veya iki yıl önce yeni bir kök oluşturun, böylece bir şeyler yanlış giderse bir zaman duvarına karşı olmadan değişmek için zamanınız olur. Böylelikle, çözülen yenisiyle ilgili sorunlarınızın çözümünü alana kadar her zaman geçici olarak eski sertifikalara geçebilirsiniz.

VPN tünelleri ilerledikçe, deneme yapmak için birkaç test edilmiş sunucu kurardım, böylece bir müşterinin makinesinde yapmadan önce yapmanız gerekenleri tam olarak anlıyorsunuz.


0
2017-09-03 23:59



Bu cevap anahtarını yeniden kullanarak bir kök sertifikayı yenilemenin mümkün olduğunu öne sürüyor. Ancak, yeni sertifikaların farklı bir imzanın olacağı ve bu nedenle mevcut müşteri sertifikalarını doğrulayamayacağından, bunun sıfırdan başlayarak farklı olmayacağından şüpheleniyorum. - Remy Blank
evet, geçerli süreyi uzatabilirsin ... ve tüm pki'leri, istemci sertifikalarını yeniden oluştur ve yeni kökü geri çek ... - ggrandes
Yeni son varlık sertifikalarının verilmesiyle ilgili kısım mutlaka doğru değildir. Bu, Yetki Anahtar Tanımlayıcısı'nın (AKID), astların CA'larında ve son varlık sertifikalarında nasıl temsil edildiğine bağlıdır. AKID dayanıyorsa {Değerli İsim, Seri Numarası}Daha sonra süreklilik sağlanacaktır. Ayrıca bkz. RFC 4518, Internet X.509 Ortak Anahtar Altyapısı: Sertifikasyon Yolu Oluşturma. - jww


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

Aşağıdaki yapılandırılabilir komut dosyasını 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

0
2018-06-30 17:33





Aynı sorunu yaşadık ve bu bizim durumumuzdaydı çünkü Debian sunucusu güncel değildi ve openSSL bu sorunu yaşıyordu:

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

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

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


0
2018-03-09 10:38