’n Sertifikaat vir ’n webwerf slegs via VPN: DNS-01 of ’n private CA?

Drie voorwaardes bepaal hoe ’n webwerf wat net via VPN bereikbaar is, sy sertifikaat moet kry: of jy ’n openbare DNS-sone beheer, of die gasheernaam in openbare logs mag verskyn, en of elke kliënt van ’n private vertrouensanker voorsien kan word. Die openbare en die private roete lewer albei ’n werkende slot en hulle beantwoord verskillende vrae. Om een te kies sonder om daardie voorwaardes uit te maak, is hoe ’n werf uiteindelik ’n openbare sertifikaat kry wat hy nie wou hê nie, of ’n interne een wat die helfte van die kliënte verwerp.

Die sertifikaat bewys die naam; die VPN en die interne DNS verskaf die pad.

Twee roetes na ’n vertroude naam

’n Openbare uitgewer met DNS-01-validasie bewys beheer oor ’n naam deur ’n TXT-rekord in ’n sone wat jy beheer, sodat die webdiens nooit ’n openbare HTTP-verbinding hoef te aanvaar nie. ’n Private CA reik bladsertifikate vir interne name uit en versprei sy vertrouensanker deur toestelbestuur, sodat geen openbare log die naam leer ken nie. Albei is wettig, en die keuse volg uit daardie drie voorwaardes eerder as uit gerief. Nie een van die roetes verskaf die roete of die resolver-inskrywing wat ’n kliënt nodig het nie.

’n Openbare sertifikaat publiseer ook die gasheernaam in sertifikaat-deursigtigheidslogs. As die naam self sensitief is, is daardie openbaarmaking ’n ontwerpbesluit eerder as ’n neweproduk wat jy later ontdek.

DNS-01 sonder om die diens bloot te stel

Die uitdagingsrekord is ’n TXT-inskrywing onder ’n gereserveerde voorvoegsel in die sone, en die uitgewer lees dit uit gesaghebbende DNS. Kies ’n ACME-kliënt en DNS-integrasie wat daardie rekord kan skep en verwyder, en magtig die opdatering nou: ’n beperkte API-kaartjie vir die sone, of ’n beheerde gasheer wat net vir validering gebruik word. Om die toepassingsbediener ’n onbeperkte registrateur-kaartjie te gee om een sertifikaat te hernu, is veel meer gesag as wat die taak nodig het. Wanneer verskeie bestellings ’n naam deel, hou hul TXT-waardes apart sodat die opruim van een nie ’n waarde verwyder wat ’n ander nog nodig het nie.

Wag vir verspreiding met ’n kontrole teen die gesaghebbende bedieners eerder as ’n vaste slaap. Verspreidingsgedrag is verskaffer-spesifiek, en ’n slaap wat vandag werk, is nie bewyse oor môre nie.

Bestuurde kliënte en doelbewus private name

Bestuurde toestelle en doelbewus private name pas goed by ’n interne CA. Versprei die vertroude uitgewer deur toestelbestuur, en reik dan bladsertifikate vir die beoogde name uit. Kontroleer watter stoor elke kliënt werklik gebruik, want een invoer in die bedryfstelsel is nie ’n universele bewering oor elke blaaier en toepassing nie. Bladvaspenning is nog ’n opsie waar dit uitdruklik ondersteun word, teen die prys van nog ’n vertrouensopdatering elke keer wanneer die blad verander.

Die verspreidingskanaal maak net soveel saak soos die sleutel: ’n wortel wat niemand installeer nie, beskerm niks.

Hernuwing is deel van die ontwerp

Watter roete jy ook kies, hernuwing het ’n eienaar en ’n prosedure nodig. Om die valideringsbewys te verfris, die nuwe materiaal te installeer en die luisteraar deur sy ondersteunde meganisme te herlaai, is drie afsonderlike stappe, en net die eerste word deur die meeste ACME-kliënte geoutomatiseer. ’n Sertifikaat wat korrek hernu maar nooit gelaai word nie, veroorsaak dieselfde onderbreking as een wat verval het.

Die sertifikaat installeer nie die VPN-roete nie en skep nie die interne DNS-rekord nie. Kliënte het steeds ’n resolver nodig wat die naam na die private adres karteer, en ’n roete om daar te kom. Toets die werf by naam vanaf ’n kliënt wat albei het.

Teken die uitgewer, die validasiemetode, die vertrouensverspreidingskanaal en die herlaaimeganisme aan. Daardie vier is die hernuwingsplan.