SSL VPN Certificaten

Ik probeer een SSL-certificaat toe te voegen aan de SSL VPN. Ik heb het tussen- en root-certificaat geïmporteerd van de CA. Wanneer ik naar SSL VPN > Serverinstellingen > Certificaatselectie ga, is de enige optie ‘Gebruik zelfondertekend certificaat’. Wat heb ik gemist om het certifcaat op de VPN toe te passen?

Het enige andere dat ik in de instellingen kan vinden, is onder Appliance > Basisinstellingen. Moet de optie ‘Schakel Client Certificaatcontrole in’ worden ingeschakeld?

Ik heb gevonden dat SonicWALL de hele keten moet bevatten in het geüploade certificaat. Vink het vakje “alle certificaten in de keten opnemen” aan bij het exporteren vanuit de bron. Of exporteer het certificaat vanaf een werkende IIS en zorg dat de hele keten is opgenomen in het geëxporteerde certificaat.

Heb je al een CSR (Certificate Signing Request) geëxporteerd/aangemaakt van de SonicWALL?

Oké, hier is een fundamenteel misverstand.

Er zijn twee delen aan elk PKI-certificaat (meestal bekend als een SSL-certificaat, hoewel we SSL niet meer gebruiken): de privésleutel en de publieke sleutel. De twee sleutels zijn cryptografisch gekoppeld en gekoppeld. Simpel gezegd: wat met de ene wordt versleuteld, kan alleen door de ander worden ontgrendeld, en vice versa. Om veiligheidsredenen mag de privésleutel nooit over het internet gaan.

Zo wordt moderne PKI gecreëerd:

Wanneer je een CSR (ondertekeningsverzoek) aanmaakt, creëert het systeem dat de CSR aanmaakt, de privésleutel. De encryptie/decryptie-informatie voor de publieke en private delen van het paar, evenals informatie zoals het onderwerp (FQDN) en andere velden zoals de naam van de organisatie, locatie, enz., worden in de CSR gecodeerd. Die CSR bevat geen privé-informatie.

Je stuurt de CSR naar een certificeringsinstantie (CA), die vertrouwen heeft in de root trust-public keys, welke in elk besturingssysteem zijn ingebouwd dat op internet wordt gebruikt (Windows, MAC, Linux) en worden onderhouden via OS-updates; de CA-trust wordt over het algemeen voor een langere periode toegestaan dan het eindgebruikerscertificaat. De root CA ondertekent de publieke sleutel (of een tussenlaag die door de root CA is ondertekend), wat een keten creëert die valideert dat het certificaat legitiem en vertrouwd is door het eindgebruiksysteem.

Dus wanneer een app, browser, enz. het PKI-certificaat van je apparaat opvraagt, wordt de publieke sleutel weergegeven, die door het eindgebruiksysteem wordt gebruikt om je beveiliging te valideren. De privésleutel werd gegenereerd met de CSR, maar blijft op het systeem en verlaat het nooit. Sommige systemen laten je toe de privésleutel te exporteren, maar niet allemaal.

In jouw situatie moet je een nieuwe (heruitgifte) van hetzelfde certificaat aanvragen, de meeste CAs bieden dit aan. Ze doen dat door het oude certificaat te intrekken (via de CRL of revocatielijst), die publiek toegankelijk is via de CA. Het bestaande certificaat op de CRL wordt ongeldig, wat een waarschuwingsbericht veroorzaakt als het nog wordt gebruikt (bijvoorbeeld als de privésleutel is gecomproteerd en het certificaat opnieuw moet worden uitgegeven). Voor zover ik weet, ondersteunen alle CA’s dit.

Je hebt dus twee opties: een CSR aanmaken en een nieuw certificaat krijgen, of de CSR gebruiken om het bestaande certificaat te laten heruitgeven. Als je het certificaat op meerdere systemen nodig hebt, genereer dan de privésleutel en CSR op een desktop, en zodra je de publieke sleutel hebt, verpak ze in een compatibel formaat voor de SonicWall (ik geloof dat PKCS12 wordt ondersteund), met een veilige wachtwoordbeveiliging. Dit wachtwoord geef je aan de SonicWall samen met het PKCS12-bestand (dat zowel publieke als privésleutels bevat, en soms ook de keten), waardoor het beschikbaar is voor gebruik.

Als je de CSR vanaf de SonicWall maakt, wordt de sleutel op de SonicWall zelf bewaard. Je hoeft alleen het antwoordbestand (de CRT) te uploaden, dat geen wachtwoord vereist omdat de privésleutel al op het systeem staat. Intern wordt het keypair gekoppeld en beschikbaar gesteld voor SSLVPN en mogelijk andere services.

Je kunt ook proberen de oude firewall te vinden en het certificaat als pakket te exporteren, dat alle relevante onderdelen in een beveiligd PKCS12-bestand plaatst. Vervolgens kun je het op de nieuwe systeem uploaden. Dit is veruit de gemakkelijkste manier, zonder dat je de bestaande cert hoeft te intrekken of domeinvalidatie voor de CA nodig hebt om te bewijzen dat je de eigenaar bent van het FQDN.

Het einddoel is eenvoudig: als je de oude certificaat wilt behouden, bijvoorbeeld omdat het op meer systemen staat (bijvoorbeeld een webserver), dan moet je dat certificaat vinden en installeren op de SonicWall, of een nieuw certificaat kopen. Als je dat niet nodig hebt en geen toegang hebt tot de oude, dan is heruitgifte de goedkoopste en veiligste optie. Voor alleen de SonicWall, genereer je de CSR op de SonicWall zelf. Wil je het op meer systemen, genereer de CSR op je PC. Voor CSR van SonicWall, upload gewoon de .crt en je bent klaar. Voor meer systemen, verpak het met de private key als PKCS12 en upload dat als één bestand.

Ik hoop dat dat helpt.

Bewerking: ik heb deze aanpak recent gedaan voor SSLVPN, dus ik ben er vrij bekend mee. Ik heb de CSR op een PC gegenereerd en het als PKCS12 gepakt met behulp van de DigiCert-tool voor Windows.

Dit was het probleem met mijn certificaat. Nadat ik het goed had geëxporteerd en geïnstalleerd, kon ik het verbinden met management via https en voor de SSL VPN. Controleer je DNS en maak interne adressen aan voor bijvoorbeeld firewall.mydomain.com of vpn.mydomain.com en begin er ‘van te genieten’.

Dank je wel!

Moest ik dat doen, ook al waren de SSL-certificaten al gekocht en in gebruik op de vorige firewall?

Als ik een nieuwe ondertekeningsaanvraag voor VPN.domain.com maak, kan ik dan mijn cert gewoon importeren via die aanvraag?

Niet 100% zeker ervan… ik weet niet of het zo verwisselbaar is of niet.

Ik denk niet dat het gebonden is aan een specifiek apparaat en alleen op dat apparaat kan worden gebruikt…

Dat gezegd hebbende, als alles in de certificaatcatalogus is geïmporteerd, zou het moeten verschijnen als een beschikbare certificaat. Als dat niet het geval is, kun je gewoon een csr genereren en teruggaan naar degene van wie je het certificaat hebt gekregen, en vragen of ze hetzelfde certificaat opnieuw kunnen uitgeven voor een nieuwe/vervangende apparaat. Ik denk dat het gratis zou moeten zijn, maar dat weet ik niet zeker.

Na het voltooien van de csr zou het certificaat als een beschikbaar certificaat moeten verschijnen om te gebruiken.

Je kunt hetzelfde certificaat niet gebruiken als je oude FW, nee. Maar je CA heeft waarschijnlijk instructies over hoe je je certificaat naar een ander apparaat overzet. Waarschijnlijk heb je een plek om een nieuwe CSR voor het nieuwe apparaat te uploaden, en het zal opnieuw uitgeven met de sleutel voor de nieuwe FW. Daarna kun je het gewoon importeren in de certificaatcatalogus van je nieuwe apparaat. Als dat is gedaan, zou het certificaat moeten verschijnen waar je het SSL-certificaat voor SSLVPN kunt kiezen.

Ik denk niet dat je het certificaat uit de oude SonicWall kunt exporteren met de privésleutel, wat waarschijnlijk de oorzaak is van dit probleem. Je kunt certificaten in sommige gevallen exporteren en opnieuw importeren, maar daarvoor moet je de privésleutel exporteren. Ik kwam hier bijvoorbeeld achter bij het upgraden van een SMA. Het certificaat wordt zonder waarschuwingen of fouten geïmporteerd, maar je kunt het niet gebruiken en als je verder zoekt, staat er dat de privésleutel ontbreekt of iets dergelijks. Zoals anderen al zeiden, is je beste optie het genereren van een CSR en het laten heruitgeven van het certificaat door de provider.

Ook niet zeker ervan, maar dat is het zeker waard om te proberen. Als het niet lukt, kun je altijd het certificaat verwijderen.

In feite is dat een goed idee… Ik adviseer je dat te proberen. Zorg er gewoon voor dat je alle velden exact hetzelfde invult als bij de originele csr.

Na import en toewijzing kun je de geldigheid van het certificaat controleren om zeker te zijn dat alles goed is (nadat je het hebt toegewezen aan je SSLVPN-verbinding).