Certificate Yaşam Döngüsü: CSR, Domain Validation, Certificate Transparency, Revocation ve 47 Günlük Gelecek

Sürüm notu: Bu yazıdaki örnekler OpenSSL 3.6, .NET 10 (SDK 10.0.402), curl ve jq ile denenmiştir; Certificate Transparency, crt.sh ve CRL (iptal edilmiş sertifikaların listesi) verileri 14 Kasım 2026'da alınmıştır, takvim tarihleri CA/Browser Forum ve Let's Encrypt duyurularından o gün tekrar kontrol edilmiştir.

Önce Tahmin Et

Bookstore'un certificate'ı Kasım 2025'te bir ticari CA'dan (sertifika veren güvenilir kuruluş) bir yıllık olarak alınmıştı. Süre dolmak üzere ve satın alma ekibi geçen yılki gibi "bir yıllık certificate" siparişi veriyor. Aynı işlemi 2029 baharında tekrar yapacaklar.

Tahmin et: bugün verilen siparişle kaç günlük bir certificate gelir? 2029'da yılda kaç kez yenileme yapmak gerekecek? CA, domain'in sana ait olduğunu her yenilemede yeniden mi kontrol eder? Cevaplar bu yazının sonundaki takvimde. Oraya gelmeden önce bir certificate'ın doğumundan ölümüne kadar geçtiği adımları sırayla izleyelim.

Key Pair ve CSR: Certificate'ı İsteyen Belge

Her şey bir key pair ile başlar ve private key ürettiğin makineden hiç çıkmaz. CA'ya giden şey CSR'dır (certificate imzalama isteği): public key, istenen isimler ve bu bilgilerin private key ile atılmış bir imzası. Bu imza, CSR'ı gönderenin private key'e gerçekten sahip olduğunu kanıtlar. OpenSSL ile:

$ openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out bookstore.example.key
$ openssl req -new -key bookstore.example.key -subj "/CN=bookstore.example" \
    -addext "subjectAltName=DNS:bookstore.example,DNS:www.bookstore.example" \
    -out bookstore.example.csr
$ openssl req -in bookstore.example.csr -noout -text -verify -reqopt no_pubkey,no_sigdump
Certificate request self-signature verify OK
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: CN=bookstore.example
        Attributes:
            Requested Extensions:
                X509v3 Subject Alternative Name:
                    DNS:bookstore.example, DNS:www.bookstore.example

self-signature verify OK satırı, CSR'ın içindeki imzanın içindeki public key ile doğrulandığını söylüyor. Önceki yazıda gördüğümüz gibi hostname'lerin yeri SAN (sertifikanın geçerli olduğu alan adları listesi); bu yüzden -addext ile istiyoruz. CSR'a yazdığın her şey certificate'a girmez. CA, kendi politikasına uymayan alanları yok sayar. Let's Encrypt gibi bir DV (yalnız alan adı sahipliği doğrulanan sertifika) CA'sı CSR'dan yalnızca public key'i ve isimleri alır; O= veya L= yazsan bile certificate'a koymaz.

Aynı şeyi .NET'te CertificateRequest ile yapabilirsin. Kendi PKI'ını (sertifika ve anahtarların yönetildiği güven altyapısı) kodla işleten bir servis veya bir provisioning aracı için kullanışlı:

using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;

string[] names = ["bookstore.example", "www.bookstore.example"];

using ECDsa key = ECDsa.Create(ECCurve.NamedCurves.nistP256);

CertificateRequest request = new($"CN={names[0]}", key, HashAlgorithmName.SHA256);
SubjectAlternativeNameBuilder san = new();
foreach (string name in names)
{
    san.AddDnsName(name);
}
request.CertificateExtensions.Add(san.Build());

File.WriteAllText("bookstore.example.csr", request.CreateSigningRequestPem());
// private key bu makinede kalır; CA'ya yalnızca CSR gider
File.WriteAllText("bookstore.example.key", key.ExportPkcs8PrivateKeyPem());

Console.WriteLine($"CSR for {string.Join(", ", names)} written; key stays on this machine.");

$ dotnet run
CSR for bookstore.example, www.bookstore.example written; key stays on this machine.
$ openssl req -in bookstore.example.csr -noout -text -verify -reqopt no_pubkey,no_sigdump
Certificate request self-signature verify OK
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: CN=bookstore.example
        Attributes:
            Requested Extensions:
                X509v3 Subject Alternative Name:
                    DNS:bookstore.example, DNS:www.bookstore.example

.NET'in ürettiği CSR, OpenSSL'inkiyle aynı yapıda. Pratikte CSR'ı elle üretmek giderek azalıyor: ACME (sertifika alma ve yenilemeyi otomatikleştiren protokol) client'ları key'i ve CSR'ı her yenilemede kendileri üretir. Yine de bir ticari CA'nın panelinden certificate alırken ya da internal CA'ya istek gönderirken bu adımı bilmek gerekir. Kural da değişmez: CSR'ı paylaşabilirsin, key'i asla.

Domain Validation: CA Domain'in Senin Olduğunu Nasıl Anlar?

CA, CSR'daki her isim için başvuranın o domain'i gerçekten kontrol ettiğini doğrulamak zorunda. Buna DCV (CA'nın alan adı kontrolünü doğrulaması) denir. ACME dünyasında HTTP, DNS ve TLS üzerinden çalışan üç standart yöntem var:

HTTP-01 en basitidir ama 80 portunu ister ve wildcard veremez. DNS-01, DNS sağlayıcının API'sine yazma yetkisi gerektirir; karşılığında wildcard ve internete hiç açılmayan sunucular için certificate mümkün olur. TLS-ALPN-01 (RFC 8737) ise ALPN (TLS handshake'inde HTTP/2 gibi protokolün seçilmesi) üzerinden yalnızca 443 ile çalışır. Bu yöntemleri Certbot ve Nginx ile uygulamak bir sonraki yazının konusu.

İki ayrıntı operasyonda önemli. Birincisi, büyük CA'lar artık doğrulamayı tek bir noktadan değil, internetin farklı bölgelerindeki birden çok noktadan yapıyor. CA/Browser Forum (CA'lar ile tarayıcı üreticilerinin kuralları birlikte yazdığı kurul) bunu 2024'te kabul ettiği SC-067 kararıyla zorunlu kıldı; buna MPIC (alan adı doğrulamasının farklı ağ noktalarından yapılması) deniyor. Amaç, tek bir ağ yolunu ele geçiren saldırganın sahte doğrulama yapmasını zorlaştırmak. Senin açından sonucu şu: firewall'da yalnızca "CA'nın IP adresine" izin vererek HTTP-01'i çalıştırmaya çalışmak işe yaramaz.

İkincisi, doğrulama sonucu bir süre yeniden kullanılır. Bugün bir domain'i doğrulayan CA, sonraki certificate'larda aynı doğrulamaya bir süre güvenebilir. Bu süre de certificate ömrüyle birlikte kısalıyor; birazdan takvimde göreceğiz. Doğrulama süresi kısaldıkça, "DNS kaydını bir kere elle ekledim, yıllarca idare eder" yaklaşımı da çalışmaz hale geliyor.

Issuance ve Certificate Transparency

Doğrulama tamamsa CA certificate'ı imzalar. Ama önce bir ara adım daha var: CT (yayımlanan tüm sertifikaların açık log'lara kaydedilmesi). CA, certificate'ın son halini imzalamadan önce bir "precertificate" üretip bunu herkese açık, yalnızca eklenebilen (append-only) log'lara gönderir. Log'lar karşılığında bir SCT (sertifikanın CT log'una kaydedildiğini gösteren imzalı kanıt) verir, yani "bu certificate'ı kaydettim" diyen imzalı bir makbuz. SCT'ler certificate'ın içine gömülür. Chrome ve Safari, SCT'leri olmayan public certificate'ları reddeder. Önceki yazıda indirdiğimiz Let's Encrypt certificate'ında:

$ openssl x509 -in le-leaf.pem -noout -text | grep -E "Log ID|Timestamp|Not Before"
            Not Before: Nov  3 13:44:34 2026 GMT
                Signed Certificate Timestamp:
                    Log ID    : 4C:63:DC:98:E5:9C:1D:AB:88:F6:1E:8A:3D:DE:AE:8F:
                    Timestamp : Nov  3 14:43:04.256 2026 GMT
                Signed Certificate Timestamp:
                    Log ID    : 46:A2:39:67:C6:0D:B6:46:87:C6:6F:3D:F9:99:94:76:
                    Timestamp : Nov  3 14:43:06.252 2026 GMT

İki SCT, iki farklı log. Log ID, log'un public key'inin SHA-256 (Secure Hash Algorithm) hash'i. Hangi log olduğunu bulmak için Chrome'un yayınladığı log listesine bakabilirsin. Satırda kesilen ilk ID'nin tam hali -text çıktısının bir sonraki satırında:

$ curl -s https://www.gstatic.com/ct/log_list/v3/log_list.json -o log_list.json
$ id=$(echo 4C63DC98E59C1DAB88F61E8A3DDEAE8FAB44A3377B5F9B94C3FBA19CFCC1BE26 | xxd -r -p | base64)
$ jq -r --arg id "$id" '.operators[] | .name as $op | ((.logs // []) + (.tiled_logs // []))[]
    | select(.log_id == $id) | "\($op): \(.description)"' log_list.json
Cloudflare: Cloudflare Nimbus2027

İkinci SCT DigiCert'in Sphinx2027h1 log'undan. Let's Encrypt'in certificate'ı Cloudflare ve DigiCert'in log'larında; log'ları işleten şirketler CA'dan bağımsız. Sistemin gücü de bu bağımsızlıkta: bir CA senin domain'in için sessizce certificate verirse, bu kayıt başka şirketlerin log'larında herkesin görebileceği şekilde kalır. Bir küçük ayrıntı daha var: Not Before, SCT'den yaklaşık bir saat önce. Let's Encrypt, saati biraz geride olan istemciler yeni certificate'ı "henüz geçerli değil" diye reddetmesin diye başlangıç zamanını bir miktar geriye çekiyor.

crt.sh ile Kendi Domain'ini İzlemek

CT log'ları herkese açık olduğu için onları tarayıp aranabilir hale getiren servisler var; en bilineni crt.sh. Kendi domain'in için kim, ne zaman certificate almış görebilirsin. Örnek olarak IANA'nın (internet adres ve numara kayıtlarını yöneten kuruluş) test domain'i example.com için süresi dolmamış certificate'lar:

$ curl -s 'https://crt.sh/?q=example.com&output=json&exclude=expired&deduplicate=Y' \
    | jq -r 'sort_by(.not_before) | reverse | .[:6][]
        | "\(.id)  \(.not_before)  \(.not_after)  \(.common_name)  \(.issuer_name)"'
29581274041  2026-09-26T22:49:11  2026-12-25T22:56:35  example.com  C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
29598205284  2026-09-26T22:34:50  2026-12-25T22:43:20  example.com  C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
29557945233  2026-09-24T00:00:00  2026-12-21T09:32:54  example.com  C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV E36
22853391369  2025-12-02T00:00:00  2026-12-02T23:59:59  example.com  C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA OV R36
22648245559  2025-11-21T00:00:00  2026-11-21T23:59:59  example.com  C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA OV R36
22625564176  2025-11-20T00:00:00  2026-11-20T23:59:59  example.com  C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA OV R36

Bu altı satır, bu yazının konusunu tek başına özetliyor. Kasım-Aralık 2025'te alınan certificate'lar bir yıllık OV (kurumun kimliği de doğrulanan sertifika). Eylül 2026'da alınanlar ise 90 gün civarında ve DV. Aynı domain'in arkasında iki farklı CA'dan ve bir CDN (statik dosyaları kullanıcıya yakın sunuculardan dağıtan ağ) sağlayıcısından gelen certificate'lar var. Kendi domain'in için bu listeye bakınca, tanımadığın bir CA'dan veya beklemediğin bir tarihte alınmış bir certificate görürsen, birisi senin adına certificate almış demektir. Ya unutulmuş bir ekip ya da bir saldırgan. Bunu sürekli izlemek ve CAA (hangi CA'ların sertifika verebileceğini belirten DNS kaydı) DNS kaydıyla hangi CA'ların certificate verebileceğini kısıtlamak serinin son yazısının ve Domain, DNS ve CDN serisinin konusu. crt.sh ücretsiz ve gönüllü işletilen bir servis; yoğun saatlerde 502 dönebiliyor, bu yüzden otomasyonda retry koy.

Revocation: CRL, OCSP ve Neden Terk Edildiği

Private key sızarsa ya da certificate yanlış verildiyse, süresi dolmadan iptal edilmesi gerekir. Buna revocation denir. İstemcinin iptali öğrenmesinin iki klasik yolu var. CRL'de CA, iptal ettiği certificate'ların seri numaralarını imzalı bir liste olarak yayınlar. OCSP'de (sertifikanın iptal durumunu anlık sorgulama protokolü) ise istemci tek bir certificate'ı CA'ya anlık olarak sorar. Önceki yazıdaki Let's Encrypt certificate'ında yalnızca CRL adresi vardı. O listeyi indirelim:

$ curl -s -o le.crl http://ye2.c.lencr.org/51.crl -w '%{http_code} %{size_download} %{content_type}\n'
200 100729 application/pkix-crl
$ openssl crl -in le.crl -inform DER -noout -issuer -lastupdate -nextupdate -crlnumber
issuer=C=US, O=Let's Encrypt, CN=YE2
lastUpdate=Nov 13 20:59:02 2026 GMT
nextUpdate=Nov 22 20:59:01 2026 GMT
crlNumber=0x18E7B669D78C2870
$ openssl crl -in le.crl -inform DER -noout -text | grep -c "Serial Number"
2347
$ openssl x509 -in le-leaf.pem -noout -serial
serial=05688C92AD512A3678DB6355831A0BFBBD32
$ openssl crl -in le.crl -inform DER -noout -text | grep -c 05688C92AD512A3678DB6355831A0BFBBD32
0

Bu liste, YE2'nin birçok "shard"ından biri ve 2347 iptal edilmiş seri numarası içeriyor. Bizim certificate bu listede yok, yani iptal edilmemiş. nextUpdate, bu listenin en geç ne zaman yenileneceğini söyler ve istemciler buna göre cache'ler.

OCSP neden terk edildi? En büyük sorun gizlilik: her OCSP sorgusu, CA'ya "şu IP adresi şu anda şu siteye bağlanıyor" bilgisini veriyor. Let's Encrypt, OCSP'yi bırakma gerekçesinde bu riski açıkça öne çıkardı. Takvimleri şöyleydi: Mayıs 2025'te OCSP adresleri yeni certificate'lardan kaldırıldı, Ağustos 2025'te responder'lar kapatıldı. CA/Browser Forum da 2023'te kabul ettiği SC-063 ile OCSP'yi public CA'lar için isteğe bağlı, CRL'i ise zorunlu yaptı. Yani OCSP artık bir zorunluluk değil, CA'nın tercihi. Üç farklı CA'nın certificate'ına baktım:

$ for h in letsencrypt.org www.digicert.com www.microsoft.com; do
    printf "%-20s ocsp=[%s]\n" $h "$(echo | openssl s_client -connect $h:443 -servername $h 2>/dev/null \
        | openssl x509 -noout -ocsp_uri)"
  done
letsencrypt.org      ocsp=[]
www.digicert.com     ocsp=[http://ocsp.digicert.com]
www.microsoft.com    ocsp=[http://oneocsp.microsoft.com/ocsp]

Let's Encrypt'te OCSP yok, DigiCert ve Microsoft'un CA'ları ise hâlâ OCSP adresi koyuyor. Bu yüzden "OCSP öldü" demek erken; doğru ifade, artık ona güvenemeyeceğin. Tarayıcılar da online kontrolü uzun süredir yapmıyor ya da kendi derledikleri listelerle yapıyor: Chrome'da CRLSet, Firefox'ta CRLite. .NET tarafında ise HttpClient varsayılan olarak revocation kontrolü yapmıyor, kendi koşumda gördüm:

Console.WriteLine(new HttpClientHandler().CheckCertificateRevocationList);
Console.WriteLine(new SocketsHttpHandler().SslOptions.CertificateRevocationCheckMode);
Console.WriteLine(new System.Security.Cryptography.X509Certificates.X509ChainPolicy().RevocationMode);

False
NoCheck
Online

HttpClient kendi başına revocation'a bakmıyor, ama elle bir X509ChainPolicy kurarsan varsayılanı Online. Önceki yazıdaki AIA (sertifikada intermediate sertifikanın adresini veren alan) deneyinde policy'ye RevocationMode = NoCheck yazmamızın sebebi buydu. Online CRL kontrolünü açarsan CRL adresine erişilemediğinde bağlantı da kurulamaz. Egress'i kısıtlı ortamlarda bunu bilerek açman gerekir.

Revocation'ın zayıflığına karşı sektörün asıl cevabı ömrü kısaltmak. Altı günlük bir certificate'ın key'i sızarsa, onu iptal etmekle süresinin dolmasını beklemek arasında pratikte fark kalmıyor. CA/Browser Forum kuralları da çok kısa ömürlü certificate'larda revocation bilgisi koymayı isteğe bağlı bırakıyor. Let's Encrypt'in 6 günlük shortlived profili bu fikrin ürünü ve üçüncü yazıda onu kullanacağız.

47 Günlük Gelecek: SC-081v3 Takvimi

Public certificate'ların maksimum ömrü on yıldır adım adım kısalıyor: Nisan 2015'te 39 ay, Mart 2018'de 825 gün, Eylül 2020'de 398 gün. Son adım, Apple'ın önerdiği ve CA/Browser Forum'da Nisan 2025'te kabul edilen SC-081v3 kararı. Oylamada CA'lardan 25 evet, 0 hayır, 5 çekimser oy çıktı; Apple, Google, Microsoft ve Mozilla dördü de evet dedi. Takvim:

• 15 Mart 2026'dan itibaren verilen certificate'lar en fazla 200 gün; domain doğrulamasının yeniden kullanım süresi de 200 gün.
• 15 Mart 2027'den itibaren en fazla 100 gün; doğrulama yeniden kullanımı 100 gün.
• 15 Mart 2029'dan itibaren en fazla 47 gün; doğrulama yeniden kullanımı yalnızca 10 gün.

Önce Tahmin Et'in cevabı burada. Bugün "bir yıllık certificate" siparişi en fazla 200 günlük bir certificate getirir. Bazı CA'lar bir yıllık "abonelik" satıp certificate'ı yıl içinde birkaç kez yeniden verir, ama dosyayı sunucuya her seferinde birinin koyması gerekir. 2029'da 47 günlük bir certificate'ı, Let's Encrypt'in önerdiği gibi ömrünün üçte ikisinde yenilersen yaklaşık her ay bir yenileme eder, yılda on iki kez. Doğrulama da en fazla 10 gün yeniden kullanılabildiği için neredeyse her yenilemede domain yeniden doğrulanacak.

Let's Encrypt bu takvimin önünden gidiyor. 90 günlük varsayılan classic profil 10 Şubat 2027'de 64 güne, 16 Şubat 2028'de 45 güne iniyor. Authorization'ın yeniden kullanım süresi bugün 30 gün; Şubat 2027'de 10 güne, Şubat 2028'de 7 saate düşüyor. 45 günlük certificate isteyenler için tlsserver profili Mayıs 2026'dan beri zaten 45 gün veriyor. Let's Encrypt, değişikliklerin staging ortamına production'dan yaklaşık bir ay önce geleceğini söylüyor; otomasyonunu orada test edebilirsin. Bu tarihler duyurulmuş planlar. Yayın sonrası değişebilirler, bu yüzden letsencrypt.org/ca/upcoming-features sayfası takipte kalmalı.

Elle Yenilemenin Sonu

Bu takvimin pratik anlamı basit: yılda bir kez takvime hatırlatma koyup certificate yenilemek artık işlemeyecek. Yenileme bir insan işi olmaktan çıkıp, sunucunun kendi yaptığı rutin bir iş olmalı. Bunun için gereken parçalar serinin geri kalanı: ACME ile otomatik alma ve yenileme (03), uygulamanın yeni certificate'ı restart'sız alması (04), yönetilen platformların bu işi senin yerine yapması (05) ve yenileme bir gün sessizce durduğunda bunu sen fark etmeden önce alarmın fark etmesi (08).

Let's Encrypt'in önerisi de bu yönde. Sabit bir "her 60 günde bir yenile" cron'u yerine ARI (CA'nın sertifikanın ne zaman yenilenmesi gerektiğini bildirmesi) ile CA'nın önerdiği zamanda yenile. ARI desteklenmiyorsa, ömrün yaklaşık üçte ikisinde yenile. 90 günlük certificate için 60. gün işe yarıyordu, 45 günlük certificate'ta bu süre certificate'ın kendisinden uzun.

Üretimde Dikkat

Envanteri şimdi çıkar. Elle yenilenen her certificate'ın bir listesi olmalı: domain, CA, nerede kurulu, kim yeniliyor. 200 günlük dönemde bu liste yılda iki kez can sıkar, 100 günde dört kez, 47 günde her ay. Otomasyona geçirilemeyen her kalem bir kesinti adayı.

Ticari CA kullanıyorsan ACME desteği olup olmadığını sor. DigiCert ve Sectigo gibi büyük CA'lar ACME endpoint'i sunuyor; OV certificate'larda da organizasyon doğrulaması ayrı yapılıp yenilemeler ACME ile otomatikleştirilebiliyor. Sözleşme yenilerken "ACME endpoint'i ve EAB (ACME hesabını CA'daki mevcut hesaba bağlama) bilgisi" bir şart olmalı.

CT izlemeyi kur. Kendi domain'lerin için yeni bir certificate verildiğinde haber veren bir izleme (crt.sh'ı periyodik sorgulayan bir job ya da bir CT monitoring servisi) hem beklenmedik issuance'ı hem de unutulmuş sistemleri ortaya çıkarır.

Revocation'a güvenme, kısalığa güven. Bir key sızdığında revocation gerekli, ama istemcilerin onu ne kadar çabuk göreceği belirsiz. Asıl koruma, key'i sızdırmamak ve certificate'ın ömrünü kısa tutmak.

Sık Düşülen Tuzaklar

CSR'ı key ile birlikte göndermek: Bazı ekipler "CA istedi" diye key'i de yükler. Hiçbir CA private key istemez; isteyen bir panel varsa bu bir alarm işaretidir.

Key'i her yenilemede aynı tutmak: Elle yenilemede eski CSR'ı tekrar kullanmak cazip, ama key'in ömrü certificate'ınkinden uzun olunca kısa ömrün güvenlik faydası azalır. ACME client'ları varsayılan olarak her yenilemede yeni key üretir. Bunu kapatmak için iyi bir gerekçen olmalı (key pinning gibi, o da beşinci yazıdaki tuzaklardan).

CT'yi gizlilik sızıntısı olarak unutmak: Certificate'a yazdığın her isim herkese açık log'lara girer. staging-payments-v2.internal.bookstore.example gibi bir isim için public certificate alırsan, iç sistemlerinin haritasını da yayınlamış olursun. İç isimler için internal CA kullan; bu yedinci yazının konusu.

"OCSP stapling açık mı?" diye uğraşmak: Let's Encrypt certificate'larında OCSP adresi yok, Nginx'te ssl_stapling on bırakmak yalnızca "ssl_stapling" ignored, no OCSP responder URL in the certificate uyarısını üretir; Nginx 1.30 ile denedim. Eski config'lerden bu satırı temizle.

Takvimi yalnızca CA'nın sorunu sanmak: CA kurala uyar ve kısa certificate verir. Kısa certificate'ı zamanında sunucuya koymak ise senin işin.

Küçük Bir Deneme

★☆☆ Kendi bir domain'in (ya da çalıştığın şirketin domain'i) için crt.sh'ta son bir yılın certificate'larını listele. Kaç farklı CA var, ömürleri nasıl değişmiş, tanımadığın bir isim veya issuer var mı?

★★☆ Bu yazıdaki .NET CSR örneğine AddIpAddress ile bir IP adresi ve bir CN dışı Subject alanı (O=Bookstore) ekle. Üretilen CSR'ı openssl req -text ile incele. Ardından Let's Encrypt'in profiller sayfasına bakarak bu alanlardan hangisinin hangi profilde certificate'a gireceğini yaz.

★★★ Bir Let's Encrypt certificate'ının CRL adresini çıkar, CRL'i indir ve nextUpdate ile lastUpdate arasındaki farkı hesapla. Aynı işlemi bir saat sonra tekrar yap: crlNumber değişti mi? Bir certificate'ı bugün iptal ettirsen, bu CRL'i cache'leyen bir istemcinin bunu en geç ne zaman göreceğini hesapla.

Certificate'ın hayat döngüsünü ve neden otomasyonun artık zorunlu olduğunu gördük. Bir sonraki yazıda bu otomasyonu kuruyoruz: ACME akışı adım adım, Certbot ile Nginx, wildcard için DNS-01, ARI ile CA'nın önerdiği zamanda yenileme ve Let's Encrypt'in profilleri.