openssl ca: index.txt içinde geçersiz son kullanma tarihi ve nasıl düzeltilir

Bir verme çalışması şurada durur: entry 22: invalid expiry date, oysa önünüzdeki talep tamamen sağlam. Şikâyet CA veritabanının ayrıştırıcısından geliyor, CSR'den değil ve sertifikayı eninde sonunda sunacak VPN istemcisinden de değil. Bu ayrım sonraki her şeyi belirler: kayıt bozuk, dolayısıyla onarım CA durumuna aittir, talebe veya eş yapılandırmasına değil. Numaralı kaydı index.txt içindeki bir satır olarak ele alın, sorun da denetlenebilir yanıtı olan sınırlı bir veri sorusuna iner.

Hatayı veritabanına yönelik bir şikâyet olarak okuyun

Her openssl ca çağrısı bir şeyi imzalamadan önce kendi metin veritabanında gezinir. Her satır bir durum harfi, bir son kullanma zaman damgası, isteğe bağlı bir iptal damgası, onaltılık bir seri numarası, bir dosya adı ve özne taşır. Bir alan ayrıştırılamadığında komut satır numarasını bildirir ve kaydın kalanını tahmin etmek yerine durur.

Bu durma bilgiçlik değil, koruyucudur. Aracın okuyamadığı bir kayıt, onu istenen öznenin zaten var olup olmadığına, bir seri numarası verilip verilmediğine veya bir sonraki CRL'nin ne içermesi gerektiğine karar veremez halde bırakır. Bozuk bir satırın ötesine geçmek, tam da aylar sonra, genellikle kimsenin açıklayamadığı bir iptal sırasında ortaya çıkan o sessiz tutarsızlığı üretirdi. Mesajı veriye yönelik bir şikâyet olarak okuyun, soruşturma CA dizininin içinde kalır.

Herhangi bir şeye dokunmadan önce CA durumunu kopyalayın

Yalnızca veritabanı dosyasını değil, tüm CA dizininin anlık görüntüsünü alın. Dizin, öznitelik dosyası, seri numarası ve CRL numarası dosyaları, özel anahtar ve verilen sertifikalar sonraki işlemlere katılır; birini geri yükleyip diğerlerini atlayan bir onarım ikinci bir olay yaratır. Varsa CA'nın kendi yedekleme yordamını kullanın ve iş boyunca planlı vermeyi duraklatın.

Başarısız komutun gerçekte yüklediği OpenSSL derlemesini ve yapılandırma dosyasını kaydedin. Kurulumlar çoğu zaman birden fazla CA dizini tutar ve hata ancak seçilen yapılandırmanın adlandırdığı veritabanına göre anlam kazanır.

Kaydı bulun ve tarih alanının kodunu çözün

Bildirilen satır numarası ilk kayıttan sayılır, bu yüzden sed -n '22p' index.txt üstünde boş veya yorum satırı olmadığını doğruladığınızda sorunlu kaydın üzerine düşer. O satırı görünür ayırıcılarla yazdırın, çünkü sekmeler ve satır sonu boşlukları yaygındır ve sıradan bir düzenleyici penceresinde görünmez.

Son kullanma alanı, genişliği yıla bağlı bir zaman damgasıdır. 2049'a kadarki değerler UTCTime içinde YYMMDDHHMMSSZ biçiminde yazılır, sonraki değerler ise dört haneli yıl ile GeneralizedTime'a geçer. İki biçimi karıştıran veya ayrıştırıcının artık dört beklediği yerde iki haneli yıl taşıyan kayıt tam da bu noktada başarısız olur. Kesintiye uğramış bir yazmadan kalan kırpılmış alan da öyle.

Kaydı başka bir CA'nın dosyasıyla değil, gönderme yaptığı sertifikayla karşılaştırın. İmzalı sertifika, geçerliliğin ne söylemesi gerektiği konusunda yetkilidir ve ayrıştırılabilir bir nesne olarak zaten vardır.

Kaydı imzalı sertifikaya göre onarın

Gerçek tarihleri şununla okuyun: openssl x509 -in issued.pem -noout -dates -serial -subject. Şunu notAfter derlemenizin o yıl için yazdığı damga genişliğine dönüştürün ve tek bir karakteri değiştirmeden önce seri numarasının düzenleyeceğiniz kayıtla eşleştiğini doğrulayın.

Yalnızca bozuk alanı düzenleyin, durum harfini ve seri numarasını koruyun, satırın geri kalanını olduğu gibi bırakın. Kayıt hiçbir imzalı sertifikayla uzlaştırılamıyorsa onu başıboş bir kayıt sayın ve satırı elle silmek yerine CA'nın kendi iptal yolundan emekliye ayırın.

Tarihi yıla ilişkin bir tahmine uydurmak için kırparak onarmayın. İki karakterlik bir kesim derlemeler arasında taşınamaz ve veritabanının gelecekteki yinelenen özne ve CRL denetimlerine bildirdiği geçerliliği sessizce değiştirir. Özgün değer kurtarılamıyorsa, yeni bir seri numarası altında yeniden verin ve eskisinin neden bırakıldığını yazın. Denetim izi onarımın parçasıdır, çevresindeki evrak işi değil.

Gitmeden önce verme ve CRL üretimini doğrulayın

Aynı yapılandırmayla bir verme çalıştırın ve satır numarası şikâyeti olmadan tamamlandığını doğrulayın. Ardından şununla bir CRL üretin: openssl ca -gencrl -config openssl.cnf ve ayrıştırılabildiğini denetleyin, çünkü hasarlı kayıt genellikle imzalama sırasında değil tam orada ortaya çıkar.

Yeni sertifikayı şununla inceleyin: openssl x509 -noout -dates -serial ve CA'nın az önce yazdığı satırla karşılaştırın. Durum harfinin ve son kullanma tarihinin sertifikayla uyuştuğunu, ayrıca openssl verify -CAfile ca.pem issued.pem komutunun hatasız döndüğünü doğrulayın. Sonra planlı vermeyi geri açın ve ilk çalışmayı izleyin, çünkü ikinci bozuk satır kendini hemen duyuracaktır.