Bu, fark edilmesi en zor SSL hatasıdır: bugün her şey yolundadır. Sertifika geçerli, tarayıcı memnun, izleme yeşil. Sorun, yenileme cron'u çalıştığı gün ortaya çıkar — ve o gün sitenin tamamı güvenlik uyarısı verir.
acme.sh her alan adı için ayrı bir yapılandırma dosyası tutar: ~/.acme.sh/<alanadi>/<alanadi>.conf. Bu dosyadaki Le_API değeri, o alan adının hangi sertifika otoritesinden yenileneceğini belirler ve ilk alım sırasında sabitlenir. Bir kez --staging ile alındıysa ya da varsayılan CA staging'e ayarlanmışsa, sonraki her yenileme staging'den gelir. Staging sertifikaları hiçbir tarayıcı tarafından güvenilmez. Mevcut üretim sertifikası geçerli olduğu sürece sorun görünmez; yenileme gününde site tamamen erişilemez hâle gelir. Kontrol: grep -r acme-staging ~/.acme.sh/*/*.conf.
Let's Encrypt'in iki ayrı ortamı vardır. Üretim ortamı, tarayıcıların güvendiği kök sertifikalarla imzalar. Staging ortamı ise aynı protokolü konuşur, aynı akışı çalıştırır, ama sahte bir kökle imzalar — adı da açıkça bunu söyler: "Pretend Pear", "Artificial Apricot" gibi.
Staging'in varlık sebebi, sıkı hız sınırlarına takılmadan otomasyon denemek. Sorun, bir denemenin kalıcı bir ayara dönüşmesidir. acme.sh alan adı yapılandırmasını ilk alım anında yazar ve bir daha sormaz:
# ~/.acme.sh/alanadi.com/alanadi.com.conf
Le_API='https://acme-staging-v02.api.letsencrypt.org/directory'
Bu satır yerinde kaldığı sürece, acme.sh --cron her çalıştığında staging'e gider. Ve şu an yüklü olan sertifika elle alınmış geçerli bir üretim sertifikasıysa, ortada bir belirti olmaz. Gerçek bir zaman ayarlı arızadır: tetikleyicisi bir kod değişikliği değil, takvimdir.
Tek satırlık kontrol, sunucudaki bütün alan adlarını bir kerede tarar:
grep -r 'acme-staging' ~/.acme.sh/*/*.conf
Çıktı boşsa temizsiniz. Eşleşen her satır, o alan adının bir sonraki yenilemede kırılacağı anlamına gelir.
Yüklü sertifikanın gerçekte kim tarafından imzalandığını da doğrudan sorabilirsiniz:
openssl s_client -connect alanadi.com:443 -servername alanadi.com </dev/null 2>/dev/null \
| openssl x509 -noout -issuer -dates
Issuer satırında "(STAGING)" ya da "Pretend" geçiyorsa sorun bugün zaten canlıdadır. Geçmiyorsa ama grep eşleşme veriyorsa, sorun yenileme gününe planlanmıştır.
Bir de şu tuzağa dikkat: tek bir sunucuda onlarca alan adı olabilir ve bunların yalnızca biri staging'e bakıyor olabilir. Kontrolü alan adı bazında değil, dizin geneline yapın.
Yapılandırma dosyasını elle düzenlemek yetmez; acme.sh o dosyayı yeniden üretebilir. Doğru yol, sertifikayı üretim sunucusunu açıkça vererek yeniden almaktır:
acme.sh --issue -d alanadi.com -d www.alanadi.com \
--server letsencrypt \
--webroot /usr/local/lsws/Example/html \
--force
--force gereklidir, çünkü mevcut sertifika henüz süresi dolmadığı için acme.sh normalde işlemi atlar. --server letsencrypt ise Le_API değerini üretime sabitler.
Aynı hatanın yeni alan adlarında tekrarlanmaması için varsayılan CA'yı da bir kez ayarlayın:
acme.sh --set-default-ca --server letsencrypt
Kurulum adımını da unutmayın: sertifikayı almak, onu web sunucusuna yüklemekle aynı şey değildir. --install-cert ile hedef dosyaları ve yeniden yükleme komutunu tanımlayın, böylece yenileme tam otomatik tamamlanır:
acme.sh --install-cert -d alanadi.com \
--key-file /etc/letsencrypt/live/alanadi.com/privkey.pem \
--fullchain-file /etc/letsencrypt/live/alanadi.com/fullchain.pem \
--reloadcmd "/usr/local/lsws/bin/lswsctrl reload"
Düzeltmeden sonra üç şeyi sırayla kontrol edin:
# 1) Yapılandırma artık üretime mi bakıyor?
grep Le_API ~/.acme.sh/alanadi.com/alanadi.com.conf
# 2) Sunucudaki sertifikayı kim imzaladı?
openssl s_client -connect alanadi.com:443 -servername alanadi.com </dev/null 2>/dev/null \
| openssl x509 -noout -issuer -enddate
# 3) Yenileme kuru çalıştırması hatasız mı?
acme.sh --cron --home ~/.acme.sh --dry-run
Üçüncü adım en değerlisidir: yenileme gününü beklemeden, o günkü davranışı bugün görürsünüz.
Bu sınıftaki arızaların ortak özelliği, siz bakmadıkça görünmemeleridir. Basit bir zamanlanmış kontrol, sürprizi ortadan kaldırır: sertifikanın bitiş tarihini ve issuer'ını günde bir kez okuyup, kalan gün 21'in altına düştüğünde ya da issuer beklenenden farklı çıktığında bildirim gönderin.
Kontrolü sunucudaki dosyadan değil, dışarıdan TLS bağlantısıyla yapın. Dosya doğru olup web sunucusuna yüklenmemiş olabilir; sizi ilgilendiren, ziyaretçinin gördüğü sertifikadır.
Staging ortamları test için vardır, ama test ayarları kalıcı yapılandırmaya sızma eğilimindedir. acme.sh'de bu sızıntı tek bir satırda saklanır ve haftalarca sessiz kalır. Yeni bir sunucu devraldığınızda ya da sertifika sorunlarını araştırırken ilk yazacağınız komut grep -r 'acme-staging' ~/.acme.sh/*/*.conf olsun — üç saniye sürer ve ileride bir günü kurtarır.
Le_API ilk alımda sabitlenir; bir kez staging olduysa hep staginggrep -r 'acme-staging' ~/.acme.sh/*/*.confopenssl x509 -noout -issuer çıktısında (STAGING) aranır--server letsencrypt --force ile yeniden alınacme.sh --set-default-ca --server letsencryptEvet, olabilirsiniz. Şu an yüklü olan sertifika elle alınmış geçerli bir üretim sertifikasıysa tarayıcı hiçbir uyarı vermez. Ancak acme.sh yapılandırması staging'e bakıyorsa, yenileme cron'u çalıştığı gün üstüne geçersiz bir sertifika kurulur. Kontrolü bugün yapmak, yenileme gününü beklemekten çok daha ucuzdur.
Güvenilir değil. acme.sh bu dosyayı kendi işlemleri sırasında yeniden üretebilir ve elle yaptığınız düzeltme kaybolabilir. Doğru yöntem sertifikayı --server letsencrypt --force ile yeniden almaktır; bu hem dosyayı doğru yazar hem de üretim sertifikasını hemen kurar.
Issuer alanından. Staging sertifikaları açıkça sahte isimlerle imzalanır: (STAGING) Pretend Pear, (STAGING) Artificial Apricot gibi. openssl s_client çıktısını openssl x509 -noout -issuer ile okuduğunuzda bu isim doğrudan görünür.
Hayır. Sorun alan adı bazındadır; aynı sunucuda on alan adından yalnızca biri staging'e bakıyor olabilir ve diğerleri sağlıklı görünürken o bir tanesi yenileme gününde kırılır. Kontrolü daima ~/.acme.sh dizininin tamamında yapın.