Şirketimde kendim yapılandırdığım (çoğunlukla HTTPS üzerinden sunulan) birkaç dahili hizmet için kendinden imzalı bir kök Sertifika Yetkilisi oluşturdum. Daha sonra bu CA ile imzalanan hizmetler için sertifikalar oluşturdum.
Şimdi bu CA'dan verilen mevcut sunucu sertifikalarını geçersiz kılmadan kök CA'ya bir x509 uzantısı (CRL dağıtım noktası) eklemek istiyorum. Mümkün mü?
Bağırsak hissim "evet" çünkü anladığım gibi, ilgili özel anahtara erişim, sertifika kimliği üzerinde "tam yetki" için gerekli ve yeterlidir. Diğer bir deyişle, oluşturulduğunda (büyük olasılıkla) ortak anahtarla birlikte sertifikaya dahil edilmiş bir tür nonce olmadığı sürece.
SSL sertifika yönetiminde hala oldukça yeniyim, ancak standart güven zincirinin temellerini anlıyorum (sanırım). Diğer PKI kriptolarının temel kullanımı konusunda da rahatım: SSH anahtarlarını yönetiyorum ve imzalama ve şifreleme için GPG kullanıyorum. Bilgisayar Bilimi okudum, ancak kriptografide sadece kendi kendini yetiştirmiş bir dabblerım.
Asla orijinal IIRC için bir CSR yapmadım (doğrudan çıktı olduğunu düşünüyorum openssl req -new -x509). Elbette orijinal CA'nın özel anahtarına sahibim ve bunu kullanarak orijinal sertifikayı bir Sertifika İmzalama İsteği'ne "tersine çevirebildim":
openssl x509 -x509toreq -in MyCA.pem -out MyCA.csr -signkey private/MyCA.key
Bunun yukarıda belirtilen nonce'yi etkili bir şekilde "çıkarmasını" ve sertifikayı yeniden oluşturmama izin vermesini umuyordum, ancak bu sefer bir crlDistributionPointsalanla ve sonuç olarak orijinal CA ile imzalanan tüm sertifikalar, istisna dışında bu yeni CA'ya karşı hala geçerli olacağını umuyordu. istemcilerin (şu anda boş olan) CRL dosyamı, alanda belirtilen HTTP URL'sinden alacağını.
Bu yüzden bir uzantı yapılandırma dosyası yaptım ext.conf:
[ cert_ext ]
subjectKeyIdentifier=hash
crlDistributionPoints=URI:http://security.mycompany.co.za/root.crl
Ve CSR'den kök CA'nın yeni sürümünü oluşturdum:
openssl x509 -extfile ./ext.conf -extensions cert_ext -req -signkey private/MyCA.key -in MyCA.csr -out MyNewCA.pem
Şimdi sertifikayı ile görüntülediğimde openssl x509 -text -in MyNewCA.pem | less
CRL uzantısı bölümünü görebilirsiniz:
X509v3 extensions:
X509v3 Subject Key Identifier:
82:D0:01:03:49:FF:30:16:FA:DC:0A:1E:C1:8C:3D:66:A1:78:FF:F8
X509v3 CRL Distribution Points:
Full Name:
URI:http://security.mycompany.co.za/root.crl`
Ama ne yazık ki! Önceden imzalanmış sertifikalarım artık bu sertifikayı doğrulamıyor:
openssl verify -verbose -CAfile MyCA.pem git.pem
git.pem: OK
openssl verify -verbose -CAfile MyNewCA.pem git.pem
git.pem: <redacted DN>
error 20 at 0 depth lookup:unable to get local issuer certificate
Çoğunlukla sertifikaların nasıl çalıştığına ve nedenine dair daha fazla bilgi ediniyorum. Ama buna yol açan soruna bir çözüm de memnuniyetle karşılarım, bu yüzden bazı arka plan bilgileri de burada.
Bu işe nasıl bulaştığını: my CA Windows üzerinde Belgesi GUI yükleyin → Explorer RMB üzerinden yüklenen ya bir kez HTTPS iç hizmetlerine büyük iş /usr/local/share/ca-certificatestakip update-ca-certificatesDebian ve Ubuntu üzerinde. Ancak son zamanlarda bir istisna ile karşılaştım: Windows'ta Git, özellikle Windows Güvenli Kanal'ı SSL arka ucu olarak kullanmak için yüklendiyse. Görünüşe göre varsayılan olarak SSL sertifikalarında bir CRL alanı olması gerektiği konusunda ısrar ediyor.
Bu yüzden gerçekten bir Windows Güvenli Kanal sorunu çünkü çalıştırmaya devam ediyorum hata mesajı tamamen Microsoft'a özgü görünüyor sanırım: fatal: unable to access 'https://angery@git.mycompany.co.za/gitblit/r/secret_project.git/': schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.
Git'i OpenSSL ile kurarsam ve CA'mı git.http.sslcainfo tarafından işaret edilen dosyaya manuel olarak birleştirirsem işe yarar, ancak kullanıcılarımın bu işlemin "kolay" Windows sertifika yükleyici GUI'sini tıklayarak.
-x509toreqmevcut kök CA'dan tüm benzersiz bilgileri kurtaracağını umuyordum , ancak ya o ya da işlemimde bir sorun var.
req -new -x509ve x509 -req -signkeyher ikisi de kendinden imzalı sertifikanın serisini rasgele bir sayıya varsayılan olarak (bu geçersiz kılsa da) etkili bir şekilde bir nonce. Alt sertifikanız (veya bunlardan herhangi biri) 'yayıncı + seri' seçeneğini ('anahtar kimliği' seçeneği yerine veya buna ek olarak) kullanarak AuthorityKeyIdentifier içeriyorsa ca, yukarı akış varsayılan yapılandırma dosyasıyla kullanmanız durumunda eskisiyle aynı seriye sahip yeni bir kök oluşturmanız gerekir; kullanın -set_serial. ...