SSL certificaat + DNS CNAME

[Babylonia]

Op mijn internetaansluiting heb ik een NL-domein, en op dat domein een SSL certificaat.

Onlangs mijn Comodo SSL certificaat vernieuwd die dan weer voor de komende 2 jaar geldig is.
Maar omdat het al weer twee jaar geleden is dat ik het vorige installeerde, weet ik niet meer goed wat ik met één regeltje moet doen.
Het past ook niet in de cyclus om dat standaard in mijn router of NAS te importeren of aan te vullen.

Wat er geleverd wordt:
- Private key
- Certificaat
- Een bundel van 3 aanvullende certificaten  (Intermediate cerificate).

Deze 3 zaken roepen geen vragen op.  Kun je in de router en NAS importeren.
Maar er wordt ook nog een "DNS record" als regel bijgevoegd.
Het betreft een  DNS CNAME  regeltje. En daar weet ik niet wat ik daarmee moet doen.

Meer informatie is er te vinden < HIER >, wat verder naar beneden onder het kopje DNS CNAME Based DCV
Maar het zegt me niet zoveel.  (Mogelijk bij de provider onder mijn domeinnaam administratie met de opties die daar voorhanden zijn ??)

Ik kan me niet herinneren dat ik er in het verleden iets mee heb gedaan.
Benadering van buiten uit voor Router - NAS en de op de NAS draaiende web-server functioneren tot nog toe goed met het nieuwe certificaat.

Die DNS CNAME regel kan ik ongebruikt laten, maar is een prettiger idee als ik de functie ervan ken.

Iemand een hint?

[Briolet]

De oplossing zit in de afkorting DCV. Ik kende deze niet, maar de eerste zin in je link geeft het antwoord al: "Domein controle validatie".

Dit is dus alleen een methode om te bewijzen dat jij het echt bent, die de aanvraag doet. Het is één van de drie mogelijke validatie methoden.

Wat ik wel heel vreemd vind is dat je schrijft: "Maar er wordt ook nog een "DNS record" als regel bijgevoegd."

Hebben zij dit opgestuurd? Als het validatie betreft, is dit juist iets wat jij moet genereren en aan hen laten zien door dit in je DNS record te plaatsen.

In elk geval lijkt me dit niet meer nodig, want je bent al gevalideerd.

Wat absoluut fout is, is je volgende quote: "Wat er geleverd wordt: - Private key"

De private key mag nooit je systeem verlaten. Dus die zouden zij nooit kunnen leveren. Via een CSR procedure kun je met die key een certificaat door hen laten maken zonder dat zij die key zelf te zien krijgen. Lekker ingewikkeld altijd omdat dit iets is wat een normaal persoon maar eens in de paar jaar doet. Routine bouw je nooit op. Dus alles op een briefje vastleggen voor over 2 jaar. 

[Babylonia]

Wat ik wel heel vreemd vind is dat je schrijft: "Maar er wordt ook nog een "DNS record" als regel bijgevoegd."

Hebben zij dit opgestuurd? Als het validatie betreft, is dit juist iets wat jij moet genereren en aan hen laten zien door dit in je DNS record te plaatsen.

Zij hebben dit inderdaad opgestuurd, maar lijkt me ook de juiste insteek?
Certificaat levering aan een SSL domein gekoppeld, krijg je alle relevante gegevens die erbij horen.
Dus ook een een "DNS record" waarin een unieke text-string is opgenomen wat gekoppeld is aan je domein.
Maar de (enige) vraag voor mij is dan, waar plaats ik dat dan?

Wat absoluut fout is, is je volgende quote: "Wat er geleverd wordt: - Private key"

De private key mag nooit je systeem verlaten.

Die verlaat mijn systeem ook niet, maar omdat het wel onderdeel is van het certificaat gekoppeld aan een NL-domein, moeten zij dat uiteraard wel leveren. Het zijn namelijk gewoon de standaard te importeren onderdelen behorend bij een certificaat.
Hieronder het menu van mijn Synology router om te importeren. De eerste 3 onderdelen die ik vernoem in mijn eerste reactie.




Heb alleen een vraag over de 4e optie, het "DNS record".

[Briolet]

Die verlaat mijn systeem ook niet,…
…maar omdat het wel onderdeel is van het certificaat gekoppeld aan een NL-domein, moeten zij dat uiteraard wel leveren.

Dat zijn twee tegenstrijdige beweringen. Als zij dat leveren heeft het al buiten je systeem gestaan. Dan weet je nooit zeker of zij een kopie bewaard hebben om al je verkeer te kunnen ontsleutelen.

De normale manier is een CSR (Certificate Signing Request) te doen. Deze genereert een private key en een bijbehorend "signing request". Die "signing request" gaat naar de certificaat authority toe en zij maken daar een ondertekend certificaat van die je terug krijgt.

De private key verlaat hierbij je systeem nooit. Bij het importeren naar de nas, laad je alle relevante zaken in.

NB: dat DNS record verhaal kun je volgens mij vergeten omdat je al het certificaat hebt. Dat is alleen nodig als je een aanvraag zonder mail doet.
------

Om de hele procedure goed te begrijpen is het leerzaam om eens op beide stoelen te gaan zitten.

- Maak een zelf ondertekend root certificaat. (op de stoel van uitgever)
- Maar een CSR (op de stoel van aanvrager)
- Onderteken dat certificaat met het root certificaat. (op de stoel van uitgever)
- Importeer dit intermediate certificaat in de nas.  (op de stoel van aanvrager)

Nu zal elk apparaat waar je de public key van die root installeert, ook dat intermediate certificaat accepteren.

[Babylonia]

De procedure met een "Certificate Signing Request" zal ik naar ik vermoed twee jaar geleden reeds hebben gedaan.
Ik kreeg nu via mail automatisch bericht dat er een nieuw certificaat voorhanden was, wat klaar stond bij mijn account gegevens.
(Circa 14 dagen voordat het oude certificaat afliep).

Die gegevens heb ik opgehaald. Niets meer niets minder.
Het wordt als zodanig in de handleiding van de betreffende beveiligingsinstanties vernoemd wat je moet doen.
En ook de tekst in mijn eerdere scherm-afdruk laat niets te raden over wat je zou moeten doen met die eerste 3 onderdelen:

     Import a certificate issued by a certificate authority [Comodo], the private key paired with te certificate,
     and the intermediate cerificate (optional)

In mijn account kan ik die verstrekte gegevens overigens ook weer wissen, zodat ze daar niet meer opgeslagen staan.

Ik vind het best zo. Ik ga die hele afwijkende toestanden die jij benoemt er niet voor omleggen, terwijl het eindresultaat precies hetzelfde is.

[Briolet]

Die ingewikkelde methode via een CSR is bedacht om ervoor te zorgen dat de private key echt private blijft. Het eindresultaat is inderdaad hetzelfde.

Nu zul jij ook niet en doelwit zijn van aanvallen, maar als je echt waardevolle zaken met dat certificaat doet dan ga je voor maximale zekerheid en gebruikt een CSR. Er zijn ook uitgevers van certificaten die je een nieuwe request laten doen als je uit onwetendheid je private key meestuurt.

[Babylonia]

Ik ben zodanig onbeduidend dat de gemiddelde "hacker" totaal niet geïnteresseerd zal zijn met hetgeen wat er op mijn server te vinden zou zijn.

[Babylonia]

Maar er wordt ook nog een "DNS record" als regel bijgevoegd.
Het betreft een  DNS CNAME  regeltje. En daar weet ik niet wat ik daarmee moet doen.

Certificaat levering aan een SSL domein gekoppeld, krijg je alle relevante gegevens die erbij horen.
Dus ook een een "DNS record" waarin een unieke text-string is opgenomen wat gekoppeld is aan je domein.
Maar de (enige) vraag voor mij is dan, waar plaats ik dat dan?

Oplossing zelf gevonden.
Ik heb in mijn account nog eens heel goed alle ingevulde gegevens bekeken wat er bij mijn NL domein hoort, IP-gegevens etc.
Nu blijken die gegevens reeds letterlijk al te zijn opgenomen bij een paar velden waaronder zo'n CNAME veld.
Maar omdat die veldjes nogal smal zijn, zie je in eerste instantie niet alle data die er is ingevuld.

(Hoe voor de hand liggend kan het zijn).  Dus feitelijk is daarmee alles compleet. 

Mooi afsluiting van het oude jaar. Goede jaarwisseling allen. 

[Briolet]

Even uit een ander draadje:

Met installatie van een nieuw SSL certificaat, waarbij ik dan tevens toch alle OpenVPN configuraties die eraan gekoppeld zijn opnieuw zou moeten updaten voor mijn VPN Clients,

Voor OpenVPN is het niet perse nodig dat je een extern gevalideerd certificaat gebruikt. Dit omdat iedereen toch al zelf een copie van het certificaat moet installeren via het configuratiebestand. Een self-signed certificaat werkt bij OpenVPN net zo goed.
Als je wilt voorkomen dat je elke 2 jaar al je cliënten moet aanpassen vanwege een nieuw Comodo certificaat, kun je een self-signed certificaat aanmaken met een veel langere geldigheid.
Zelf liep ik er tegenaan dat Let's Encrypt het certificaat elke 3 maand vervangt. Ik heb daarom ook een eigen certificaat gemaakt die alleen bij OpenVPN gebruikt wordt.

[Babylonia]

Voor OpenVPN alleen heb je dat SSL certificaat inderdaad niet nodig.
Maar gebruik de verbinding ook op andere wijze waardoor ik dat officieel gevalideerd SSL certificaat wel nodig heb. Twee verschillende certificaten in het gebruik laten zich niet installeren. Zo gauw je een nieuw SSL certificaat importeert heeft dat direct gevolgen voor de certificaten die geldend zijn voor OpenVPN.

[Pippin]

Het is altijd ten zeerste aanbevolen voor OpenVPN een eigen CA te hebben, m.a.w. volledig in eigen beheer en gescheiden van de rest.
Jullie berichten zijn tegenstrijdig, kan het nu wel of niet...?

[Briolet]

Ik weet niet wat Babylonia met "ergens anders nodig" bedoelt.

Normaal gesproken kun je aan "VPN Server" een specifiek certificaat toevoegen.:



Alleen dat instellen is buggy. Ik moet soms wel 10x dat certificaat selecteren en bevestigen klikken voordat de instelling opgeslagen wordt. Dat geld voor het toekennen van alle certificaten. Dus je mag er niet op vertrouwen dat je keuze ook aktief is. Je moet het controleren.

Verder zit er inderdaad ook nog ergens een bug, want toen ik keek stond het default certificaat gekozen en werkte OpenVPN niet. Pas na het bedoelde certificaat op de nas te kiezen, werkte OpenVPN weer.

Moet ik in de gaten houden. Het default certificaat is van Let's Encrypt dat elke 3 maand aangepast wordt. Ik heb er in totaal 6 certificaten in staan (3x Let's Encrypt en 3x self signed) en heb er eigenlijk nooit problemen mee gezien.

[Babylonia]

Waar komt dat plaatje vandaan wat je toont?  Die lijst ken ik helemaal niet?  Gezien de volgende tekst, vermoed ik uit de NAS.

Pas na het bedoelde certificaat op de nas te kiezen, werkte OpenVPN weer.

De samenhang met SSL certificaat en VPN is in mijn geval specifiek gerelateerd aan de functies van een Synology ROUTER, niet die in de NAS.
Bedoeld voor gebruik met het VPN Plus package voor de router.  Dat pakket is niet voor de NAS beschikbaar.

Wat verwarrend, omdat dit draadje over het SSL certificaat onder "Overige software" is gezet, en het al gauw lijkt dat het dan betrekking heeft op het gebruik "alleen" in de NAS.  Ik gebruik het SSL certificaat zowel voor de NAS als de router. Maar voor VPN specifiek op de router.
Waarbij jezelf overigens ook refereert naar een ander draadje specifiek onder de Router sectie van het forum.
Met de aanhaling die je eruit hebt gelicht is helaas de URL van het originele bericht niet mee genomen, zodat de context verloren gaat.
Maar het komt dus < HIER > vandaan (2e alinea).

Zo gauw ik een SSL certificaat importeer (in de router) heeft dat effect op de uitwerking van certificaten gebruikt bij OpenVPN.
Er is slechts één plek in de router waar ik certificaten kan importeren.  Voor Open VPN "exporteer" ik erna dan het configuratiebestand.
(Waarbij dat in VPN Plus is gecombineerd met meteen eronder het certificaat).
Verder houd ik me niet bezig met Let's Encrypt certificaten. Ik gebruik juist gewoon een officieel validated certificaat.
Dat zou toch niet uit moeten maken?