Müsait — Yerel Dijital Ürünler
HCA · Studio
TR — İletişim ↗
Teknik Not 07 · Sunucu

acme.sh staging tuzağı ve zamanlanmış felaket

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.

Araç
acme.sh
Belirti
Bugün yok, 60 gün sonra var
Kanıt
Le_API satırı
Kısa cevap

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.

Neden sessiz

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.

Tespit

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.

Düzeltme

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"

Doğrulama

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.

Erken uyarı

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.

Özet

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.

Hızlı referans
Tuzak
Le_API ilk alımda sabitlenir; bir kez staging olduysa hep staging
Neden sessiz
Yüklü üretim sertifikası geçerli olduğu sürece belirti yok
Tetikleyici
Kod değil, takvim — yenileme cron'unun çalıştığı gün
Tespit
grep -r 'acme-staging' ~/.acme.sh/*/*.conf
Doğrulama
openssl x509 -noout -issuer çıktısında (STAGING) aranır
Düzeltme
--server letsencrypt --force ile yeniden alın
Kalıcı önlem
acme.sh --set-default-ca --server letsencrypt
İzleme
Issuer ve kalan günü dışarıdan TLS bağlantısıyla kontrol edin
Sık Sorulan Sorular

Staging sertifika tuzağı hakkında.

Sertifikam şu an geçerli görünüyor, yine de risk altında mıyım?

Evet, 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.

Yapılandırma dosyasındaki satırı elle düzeltsem yetmez mi?

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.

Staging sertifikası nasıl anlaşılır?

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.

Bir sunucuda tek alan adını kontrol etmek yeterli mi?

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.

Teklif ve Uygunluk

Bir fikriniz mi var?
Yarım cümle de olur.