INTEGRITY Dokumentace

← Cloudflare for Platforms / cloudflare-for-platforms / cloudflare-for-saas / security / certificate-management / issue-and-validate / validate-certificates

HTTP

Ověření HTTP zahrnuje přidání tokenu DCV na origin vašeho zákazníka.

Jednu metodu ověření certifikátu si vyberete, když vytvořte vlastní hostitelský název. API přijímá jeden ssl.method hodnota: http, txt, nebo email.

Non-wildcard vlastní hostitelské názvy

Pokud váš vlastní hostitelský název neobsahuje zástupný znak, Cloudflare se pokusí dokončit DCV pomocí Ověření HTTP poté, co hostname směřuje na váš cíl SaaS, i když jste vybrali TXT pro vaši metodu ověření.

Toto ověření HTTP by mělo proběhnout úspěšně, pokud hostitelský název vašeho zákazníka směřuje na váš cíl SaaS a zákazník nemá žádné záznamy CAA které blokuje vámi zvolenou certifikační autoritu.

Wildcard vlastní hostitelské názvy

Ověření HTTP DCV není u zástupných certifikátů povoleno. Použijte Ověření TXT místo toho. Můžete také nakonfigurovat Delegovaná DCV k automatizaci ověření pomocí záznamů TXT.

Metody ověření

HTTP (automaticky)

Pokud upřednostňujete jednoduchost a vaši zákazníci zvládnou i pár minut výpadku, můžete se spolehnout na automatické ověření HTTP od Cloudflare.

Jakmile vytvořte nový hostitelský název a vyberte http metodu ověření, vaši klienti musí pouze přidat CNAME záznam na váš $CNAME_TARGET a o zbytek se postará Cloudflare.

Automatické ověření HTTP funguje za provozu. Jakmile váš zákazník nasměruje hostitelský název na váš cíl SaaS, Cloudflare může z edge sítě obsloužit HTTP token DCV od CA a dokončit ověření certifikátu.

Během tohoto období může hostname směrovat na Cloudflare ještě předtím, než certifikát dosáhne ssl.status: active. Pokud potřebujete, aby byl certifikát aktivní ještě předtím, než váš zákazník změní DNS, použijte Ověření TXT nebo Delegovaná DCV místo toho.

Co se stane po vytvoření vlastního hostitelského názvu

Cloudflare osloví jednoho z poskytovatelů certifikační autority (CA) a požádá ho o vydání certifikátu pro daný hostname. CA poté Cloudflare informuje, že je nutné prokázat kontrolu nad tímto hostname vrácením $DCV_TOKEN v zadaném $DCV_FILENAME; token i název souboru generuje CA náhodně a Cloudflare je předem nezná.

Pokud například vytvoříte nový vlastní hostname pro site.example.com, CA po nás může požadovat, abychom vrátili hodnotu ca3-38734555d85e4421beb4a3e6d1645fe6 pro požadavek na http://site.example.com/.well-known/pki-validation/ca3-39f423f095be4983922ca0365308612d.txt". Jakmile tuto hodnotu od CA obdržíme, zpřístupníme ji na naší edge síti a požádáme CA o potvrzení, že tam je, aby mohla dokončit ověření a objednávku certifikátu.

Pokud chcete dokončit proces vydání dříve, než požádáte zákazníka o aktualizaci jeho CNAME (nebo než změníte překlad cílového CNAME tak, aby procházel přes proxy Cloudflare), zvolte jinou metodu ověření.

HTTP (ručně)

Jakmile vytvořte nový hostitelský název a vyberete tuto metodu ověření, po několika sekundách uvidíte následující hodnoty:


Na svém origin serveru proveďte http_body dostupný v TXT záznamu na cestě uvedené v http_url. Tato cesta by měla být také veřejně přístupná komukoli na internetu, aby k ní měla přístup vaše CA.

Zde je příklad konfigurace NGINX, která by vrátila token:

location "/.well-known/pki-validation/ca3-0052344e54074d9693e89e27486692d6.txt" {
       return 200 "ca3-be794c5f757b468eba805d1a705e44f6\n";
}

Jakmile je vaše konfigurace aktivní, ověřte, že je textový soubor DCV na místě pomocí curl:

curl "http://http-preval.example.com/.well-known/pki-validation/ca3-0052344e54074d9693e89e27486692d6.txt"
ca3-be794c5f757b468eba805d1a705e44f6

Token je platný po dobu jednoho kontrolního cyklu. V dalším kontrolním cyklu Cloudflare požádá certifikační autoritu, aby URL znovu zkontrolovala, dokončila ověření a vydala certifikát.

Pokud chcete vyžádat okamžitou opětovnou kontrolu, namísto čekání na další opakování, odešlete Požadavek PATCH se stejnými hodnotami jako váš původní POST požadavek.