Persoonlijk
Wij zoeken altijd een oplossing op maat, indien nodig komen we bij u langs.
Bereikbaar
Wij zijn altijd bereikbaar via een van onze communicatiekanalen.
Veiligheid voorop
Wij zoeken altijd oplossingen op basis van de beste veiligheid.
Hieronder staan de meest recente handleidingen voor het gebruik of het instellen van producten. Zoekt u een handleiding en staat deze er niet bij? Neem dan contact met ons op. Wij helpen u graag verder.
Om gebruik te kunnen maken van tweestapsverificatie op uw Networking4all account, heeft u een applicatie nodig die tweestapsverificatiecodes kan genereren. Hiervoor kunt u de app 'Google Authenticator' (voor Android en voor Iphone) op uw telefoon installeren. Volg de stappen op uw telefoon om de app te installeren. Houd vervolgens uw telefoon bij de hand.
Log vervolgens in op de Networking4all portal. Ga naar het menu 'Mijn account' en klik op de menu-optie 'Mijn gegevens'. Ga naar het tabblad 'Account'. Onderaan deze pagina staat de optie 'Two-factor authentication.'
Open de app die u zojuist heeft geïnstalleerd op uw telefoon en druk op het rode plus-icoon. Kies voor de optie 'Een streepjescode scannen'. Uw telefoon zal nu de camera inschakelen; er verschijnt een rood vakje in beeld. Scan de QR code op uw Account-pagina zo, dat het vierkant binnen het rode vakje valt.
Zet de optie 'Two-factor authentication' op 'actief' en klik op Opslaan.
Inloggen
Vanaf de eerstvolgende keer dat u inlogt op de Networking4all portal, krijgt u eerst het inlogscherm te zien voor uw gebruikersnaam en wachtwoord. Nadat u deze gegevens heeft ingevuld, zal er worden gevraagd om de extra beveiligingscode. Open hiervoor de app op uw telefoon. Google Authenticator genereert automatisch na enkele tientallen seconden een nieuwe code. Vul de code in die hoort bij uw Networking4all account.
De common name is de hostnaam waarvoor een SSL certificaat wordt aangevraagd. Deze kan per type SSL certificaat verschillen. In de meeste gevallen bestaat een common name uit de volledige hostnaam, bijvoorbeeld 'www.uwdomeinnaam.nl'. In het geval van een wildcard is dit echter '*.uwdomeinnaam.nl'. Daarnaast zijn er ook non-web toepassingen voor SSL waar een common name voor wordt gebruikt, zoals e-mail certificaten. In dat geval is de common name vaak het volledige e-mailadres.
Wanneer u een certificaat koopt bij Networking4all, krijgt u er gratis advies en ondersteuning bij. Dit betekent dat wij actief monitoren wanneer uw certificaat dreigt te verlopen, en of dat het certificaat nog wel goed en veilig is geïnstalleerd. Ook over belangrijke beveiligingsupdates houden wij u actief op de hoogte.
Een Let's Encrypt certificaat is weliswaar gratis, maar heeft geen van de extra servicevoordelen die Networking4all biedt. Zo is een Let's Encrypt certificaat standaard maar 3 maanden geldig, en bent u zelf verantwoordelijk voor de tijdige renewal van uw certificaat.
SSL is gebaseerd op de versleuteling van gegevens met behulp van een private en een public key.
Private key
Een private key wordt gecreëerd door een stukje automatisch gegenereerde tekst te converteren naar een key-bestand met behulp van een wiskundig algoritme, waardoor het een unieke waarde krijgt. Vervolgens wordt met dit key-bestand een CSR gegenereerd die weer gebruikt wordt om een SSL certificaat aan te maken. In dit CSR-proces wordt ook de public key aangemaakt. De private key moet te allen tijde geheim blijven. Met deze sleutel kan versleutelde data worden ontcijferd en berichten die met een certificaat ondertekend worden, worden versleuteld.
Public key
De public key wordt tijdens het genereren van een CSR aangemaakt en mag publiek worden verspreid. Een public key wordt bijvoorbeeld gebruikt om informatie te versleutelen die alleen de eigenaar van de private key mag ontvangen. Alleen de combinatie van de public en private key kan deze gegevens vervolgens ontsleutelen. Een public key kan ook gebruikt worden om te verifiëren dat een bericht is gestuurd door de eigenaar van de private key.
Versleutelingsalgoritme
Hoe sterk de encryptie van een certificaat is, is grotendeels te danken aan het versleutelingsalgoritme dat gebruikt is om de private key te genereren. Hackers zijn er dus op gebrand om deze versleutelingsalgoritmes te kraken: wanneer het algoritme op straat ligt, kan er met behulp van de public key worden teruggerekend naar de private key. Het RSA algoritme was tot voor kort het meest gebruikte algoritme, maar het ECC algoritme, of Elliptic Curve Cryptography algoritme, krijgt steeds meer voet aan de grond. Dit algoritme kan een veel kleinere key creëren die nog steeds net zo veilig is als de veel langere RSA keys. Zo is een ECC key van 228 bits net zo veilig als een RSA key van 2380 bits. Steeds meer Certificate Authorities stappen daarom over op ECC keys.
Een wildcard certificaat kan meerdere subdomeinen beveiligen onder één unieke domeinnaam. Een wildcard certificaat wordt gemarkeerd met een asterisk, bijvoorbeeld *.networking4all.com. Hiermee kunnen meerdere onderliggende diensten worden beveiligd, zoals sip.networking4all.com of webmail.networking4all.com. Ook is het mogelijk om een wildcard certificaat op meerdere servers te installeren.
Bij het aanschaffen van een wildcard certificaat is het belangrijk om rekening te houden met subdomein-levels. Dat wil zeggen dat een wildcard voor *.networking4all.com wel test.networking4all.com, maar niet test.webmail.networking4all.com kan beveiligen. Daarvoor moet een apart wildcard certificaat worden aangevraagd.
Een wildcard certificaat is alleen beschikbaar als domein gevalideerd (DV) of organisatie gevalideerd (OV) certificaat. Het is niet mogelijk om een wildcard EV certificaat te bestellen.
Wildcard SAN
Een Wildcard SAN certificaat biedt dezelfde mogelijkheden als een gewoon wildcard certificaat, maar biedt daarnaast de mogelijkheid om wildcards binnen de SAN namen op te nemen. Onderstaand voorbeeld legt dit uit:
Het Wildcard SAN certificaat is wel alleen beschikbaar als OV certificaat. Met dit type SAN certificaat heeft u maximaal 100 SAN namen tot uw beschikking.
In tegenstelling tot bij gewone certificaten neemt het wildcard SAN certificaat niet standaard naast de domeinnaam zonder www ook de domeinnaam met www in zich op. Als deze ook beschermd moet worden, zal die dus toegevoegd moeten worden aan het certificaat als aparte SAN naam. Dit geldt niet voor de common name: deze wordt zowel met als zonder www ondersteund.
Aanvragen
Wildcard certificaten en wildcard SAN certificaten kunnen aangevraagd worden via de SSL wizard.
Het intermediate certificaat is een certificaat dat is uitgegeven als tussenlaag tussen de Certificate Authority en het eindgebruikerscertificaat. Het dient als verificatiemiddel om aan te geven aan een browser dat een certificaat op een veilige, geldige bron, het rootcertificaat van de CA, is gebaseerd. Deze rootcertificaten zijn standaard opgenomen in de browsers.
Het intermediate certificaat wordt standaard meegeleverd met elk besteld certificaat en wordt tegelijkertijd op de server geïnstalleerd. Aan de hand van de fingerprint van het intermediate certificaat dat in het eindgebruikerscertificaat is opgenomen, kan een browser controleren of het certificaat op een geldig rootcertificaat is gebaseerd.
Het kan voorkomen dat een eindgebruikerscertificaat op meerdere, opeenvolgende intermediate certificaten is gebaseerd. In dat geval moeten alle van toepassing zijnde intermediate certificaten op de server worden geïnstalleerd. Alleen dan kan de browser de ketting van fingerprints en certificaten terugleiden naar het rootcertificaat dat in de browser staat.
Het rootcertificaat is het begin van de chain of trust waarop een SSL certificaat wordt uitgegeven. Het rootcertificaat behoort toe aan een Certificate Authority. Aan de hand van het rootcertificaat worden intermediate certificaten uitgegeven die weer de mogelijkheid bieden tot het registreren van SSL certificaten voor eindgebruikers. Deze certificaten worden door overerving vanuit het rootcertificaat automatisch gezien als vertrouwd.
Elke browser of service die gebruik maakt van SSL certificaten bevat een lijst met goedgekeurde rootcertificaten. Bij het bezoeken van een website met SSL verbinding, wordt de geldigheid van een certificaat gecontroleerd door de fingerprints van het certificaat en de bijbehorende intermediate certificaten te controleren, totdat de fingerprint van het rootcertificaat is bereikt. Deze wordt dan gecontroleerd tegen het rootcertificaat in de browser. Als deze niet overeenkomen, is het certificaat dus niet geldig.
SNI staat voor Server Name Indication. SNI is een aanvullend protocol voor het SSL/TLS protocol dat is ontwikkeld als oplossing voor het opraken van IPv4 adressen. Door tijdens het handshakeproces aan te geven met welke hostnaam de client verbinding wil maken, kunnen er meerdere HTTPS-beveiligde websites met elk hun eigen SSL certificaat op dezelfde server, met hetzelfde IP adres en TCP port nummer, gehost worden.
Om gebruik te kunnen maken van SNI moet de SSL/TLS library het SNI protocol ondersteunen. Sinds 2004 wordt het protocol ondersteund door de OpenSSL library, maar omdat deze library zowel op software- als OS-niveau aangeroepen kan worden, zijn er browsers die SNI niet op elk OS ondersteunen. Dit geldt voornamelijk voor oudere software.
De volgende browsers of browser/OS combinaties bieden geen ondersteuning voor SNI:
De IBM HTTP server biedt ook geen ondersteuning voor SNI.
DANE is een beveiligingsprotocol dat verder gaat dan het standaard HTTPS protocol in het beveiligen van de vertrouwensketen tussen server, Certificate Authority en gebruiker.
In het huidige HTTPS protocol wordt er van uitgegaan dat certificaten die uitgegeven worden door een vertrouwde CA ook automatisch als veilig worden beschouwd. Hierbij wordt het root certificaat van een CA gebruikt als een zogenaamd trust anchor. Dit betekent echter dat wanneer een vertrouwde CA gehackt wordt, er valse certificaten kunnen worden uitgegeven die door browsers niet als onveilig worden verklaard.
DNSSEC
DNSSEC is in het leven geroepen om de veiligheid van domeinen op een hoger niveau te trekken. In dit protocol wordt een apart certificaat aangemaakt voor de nameserver van een domein. Een samenvatting van dit publieke certificaat wordt vervolgens aan de desbetreffende registry afgegeven. Bij elke request vanuit een browser wordt dan niet alleen de nameserver gegevens, maar ook de handtekening die bij het certificaat hoort teruggegeven. Als deze handtekening niet overeenkomt met de gegevens zoals ze terugkomen van de nameserver, of helemaal ontbreekt in die response, is de DNS data dus ongeldig.
DANE
DANE is een protocol dat alleen werkt als DNSSEC actief is. Dane laat de browser kijken naar het TLSA record. In dit record staat vervolgens de public fingerprint van een certificaat waarvan de gebruiker zelf aangeeft dat het veilig is. Dit kan bijvoorbeeld een intermediate certificaat zijn van de CA die het certificaat heeft uitgegeven dat op de server staat, maar kan ook de fingerprint van het certificaat zelf zijn.
Het aanmaken van een TLSA record kan gemakkelijk online worden gedaan met een generator als de TLSA Generator op SSL-tools.net.
Cipher suites zijn een belangrijk onderdeel van de serverconfiguratie. Het zijn vastgelegde combinaties van verschillende algoritmes die worden gebruikt in het versleutelde verkeer tussen server en gebruiker. Hierin zijn de volgende onderdelen opgenomen die samen de cipher suites definiëren:
Handshake
Bij elke afzonderlijke verbinding tussen de server en een bezoeker van een website wordt een handshake uitgevoerd. Tijdens deze handshake zoekt de gebruiker contact met de server door middel van een ClientHello en een ServerHello, waarbij de twee informatie uitwisselen over de cipher suites waar ze bekend mee zijn. De server bepaalt dan aan de hand van de lijst met overeenkomende cipher suites welke het best bruikbaar is, en gebruikt de protocollen zoals deze in die cipher suite zijn opgenomen voor de verdere versleuteling van het verkeer.
Diffie-Hellman
De opbouw van de cipher suite is voor het bepalen van de meest veilige optie voor de server van groot belang. Welke ciphers het meest veilig zijn is zeer afhankelijk van de persoonlijke voorkeur van de eigenaar van de server, maar er wordt een voorkeur gegeven aan cipher suites die gebruik maken van ECDHE, een protocol dat gebruik maakt van het zeer lastig te kraken ECC algoritme.
Daarnaast wordt gekeken naar welk cryptografisch protocol gebruikt wordt. Tegenwoordig is TLS 1.2 de norm. De voorgangers, SSL 2.0 en 3.0, worden gezien als onveilig door hun zwakke punten die Man in the Middle attacks konden uitnodigen. Zo was de handshake in SSL 2.0 niet beveiligd, waardoor een hacker er voor kon zorgen dat er een zwakkere cipher suite werd gekozen dan normaal.
Configureren
De beheerder van een website kan door regelmatig updaten en de juiste configuraties te gebruiken er voor zorgen dat de beste cipher suites worden gebruikt. Een webserver maakt gebruik van webserver software, zoals Apache of nginx, die op hun beurt weer gebruik maken van zogenaamde software libraries zoals OpenSSL. Hierin staan alle bekende cipher suites vermeld. Het regelmatig bijwerken en updaten van OpenSSL is daarom zeer belangrijk, omdat een cipher suite opgeslagen moet zijn in de library alvorens deze aangeroepen en gebruikt kan worden door de serversoftware.
Gerelateerde blogartikelen:
Een Certificate Authority Authorisation Record wordt gebruikt om te bepalen welke Certificate Authorities (CA's) gerechtigd zijn om certificaten uit te geven voor een domein. Hiermee kan worden voorkomen dat er certificaten voor een domein worden uitgegeven door een andere CA. Door een CAA record in te stellen kan de eigenaar van een domein ook op de hoogte worden gesteld van illegale pogingen om een certificaat uitgegeven te krijgen op het domein. CAA records kunnen ingezet worden voor het gehele domein, of specifieke hostnamen. Ze zijn overdraagbaar naar subdomeinen, tenzij die overschreven worden door een eigen record. CAA records kunnen op zowel single-domain als wildcard domeinen worden ingezet.
CAA records kunnen ingezet worden voor het gehele domein, of specifieke hostnamen. Ze zijn overdraagbaar naar subdomeinen, tenzij die overschreven worden door een eigen record. CAA records kunnen op zowel single-domain als wildcard domeinen worden ingezet.
Een CA moet controleren op het bestaan van een CAA record
Het instellen van een CAA record door de gebruiker is niet verplicht. Echter wel aan te raden als extra beveiligingslaag. Een CA is vanaf 8 september 2017 verplicht dit record te controleren. Wanneer minimaal één CAA record ingevuld is en de CA waarvoor u een certificaat wilt aanvragen staat er niet bij, mag de CA geen certificaat voor het betreffende domein uitgeven. De controle van het bestaan van een CAA record vindt plaats tijdens het aanvragen van een SSL certificaat. Wanneer u later een CAA record aanpast of toevoegt (bijvoorbeeld een jaar later), dan zal een SSL certificaat dat vóór die datum is aangevraagd gewoon geldig blijven.
CAA record controleren?
U kunt controleren of het CAA record gevonden kan worden en welke waarde daar ingesteld zijn. Gebruik hiervoor de Networking4all Qualys SSLLABS scan.
CAA record instellen
Het instellen van een CAA record werkt volgens een vast format. Hierbij zijn drie verschillende tags te gebruiken:
Bij het aanmaken van een CAA record moet gekozen worden voor één van deze tags. Een voorbeeld van een CAA record is:
Extra CAA policy
Het is mogelijk om voor een domeinnaam een extra policy in te stellen. Hierin kunt u bijvoorbeeld aangeven dat voor deze domeinnaam of hostname alleen maar EV SSL certificaten uitgegeven mogen worden. Hieronder een voorbeeld, waarin alleen EV certificaten mogen worden uitgegeven door de CA DigiCert:
CAA records per CA
Hieronder staan de CAA record voorbeelden per CA:
OCSP staat voor Online Certificate Status Protocol. Dit is een browser-protocol dat de geldigheid van een SSL certificaat controleert met behulp van een whitelist.
CRL
Standaard wordt deze geldigheid gecontroleerd met behulp van de Certificate Revocation List: een blacklist van de Certificate Authority waarop de CA alle certificaten plaatst die gerevoked zijn. Bij elk bezoek van een website met een certificaat dient de browser vervolgens een verzoek in bij de CA, waarop de CA de CRL terugstuurt. Vervolgens kan de browser controleren of het certificaat in kwestie voorkomt op de blacklist. Is dat het geval, dan kan de browser een foutmelding geven aan de gebruiker.
Het gebruik van een CRL komt wel met nadelen: de browser moet bij elk certificaat opnieuw de CRL opvragen, wat een zekere hoeveelheid verkeer oplevert naar de CA, des te meer als het gaat om een populaire website met veel verkeer. Dit kan zelfs zoveel verkeer opleveren dat het misbruikt kan worden voor een DDoS aanval. Maar mocht de CA niet bereikbaar zijn, dan kan er geen CRL worden teruggegeven die de controle toestaat en kan de browser er incorrect van uitgaan dat het certificaat te vertrouwen is. Daarnaast is het ook van belang dat de CA de CRL up to date houdt.
OCSP
OCSP werd bedacht als alternatief voor de CRL, en werkt met een whitelist in plaats van een blacklist. In plaats van de volledige blacklist op te vragen, stuurt de browser nu slechts het certificaat waarvan de status moet worden gecontroleerd. De CA stuurt de status van het certificaat terug naar de browser, die daarop kan handelen. Deze methode vraagt om veel minder dataverkeer naar de CA, en een veel compactere afhandeling in de browser, omdat er maar een kleine response status hoeft te worden uitgelezen. Daarnaast stuurt de browser de gebruiker niet automatisch door naar de website als er geen contact gemaakt kan worden met de CA: de gebruiker krijgt dan een foutmelding te zien.
Maar ook OCSP heeft zijn nadelen: de kans op overbelasting van het systeem van de CA is alsnog aanwezig, zij het kleiner. De request naar de CA verloopt ook altijd over HTTP, waardoor er ruimte is voor hackers om mee te kunnen luisteren. Ten slotte is het maar de vraag hoe veilig het is om een derde partij te betrekken bij de geldigheidscontrole van een certificaat, zelfs als die derde partij de CA is die het certificaat heeft uitgegeven.
OCSP Stapling
Bij OCSP Stapling is het niet de browser, maar de server waarop het certificaat staat die een OCSP request naar de CA stuurt. Dit doet hij regelmatig: zo blijft het resultaat altijd up to date. Vervolgens maakt de server het resultaat vast aan de SSL handshake die aangeroepen wordt als er verbinding gemaakt wordt met de server vanuit een browser. Dit heeft meerdere voordelen: er is minder verkeer nodig tussen de server en de browser, omdat het verzoek van de browser meteen wordt beantwoord met het terugkrijgen van de SSL handshake. Het OCSP verzoek naar de CA vanaf de server is ook een gesloten circuit, en het resultaat dat de server ontvangt moet altijd ondertekend zijn door de CA om geldig te zijn. Zo kan er geen misbruik van dit systeem worden gemaakt. Het resultaat wordt voor langere tijd vastgehouden, waardoor het stabieler is dan CRL of OCSP. Mocht de CA niet bereikbaar zijn, heeft de server dus alsnog een resultaat dat gebruikt kan worden ter verifiëring van het certificaat. En wanneer de server dit resultaat niet terug kan geven aan de browser, kan er alsnog een normaal OCSP request worden uitgevoerd.
OCSP Stapling is een setting op uw webserver installatie. Het inschakelen van deze optie is afhankelijk van de software die draait op uw server. Raadpleeg de handleiding van uw softwarepakket om OCSP Stapling te configureren.
Gerelateerde blogartikelen:
HTTP Strict Transport Security, oftewel HSTS, is een response header die toestaat dat browsers gedwongen worden voor alle opvolgende requests die ze naar een server sturen, HTTPS te gebruiken. Dit betekent dat een bezoek naar http://www.networking4all.com automatisch wordt doorgestuurd naar https://www.networking4all.com, zonder dat er eerst een request wordt gestuurd voor de HTTP-pagina. Dit voorkomt ook dat er tijdens een Man in the Middle attack een downgrade attack kan worden toegepast die het verkeer over een onbeveiligde verbinding zou dwingen in plaats van de versleutelde HTTPS-verbinding.
HSTS werkt zo, dat niet alleen direct verkeer naar de website in kwestie automatisch wordt omgezet naar een HTTPS-verbinding. Ook links die op een externe pagina staan en die linken naar de HTTP-pagina worden automatisch naar de HTTPS-pagina gestuurd. Daarnaast voorkomt het gedwongen gebruik van HTTPS ook dat via cookies de sessie key kan worden gekaapt.
Het instellen van HSTS is een kwestie van het toevoegen van één response header aan de config:
De server stelt zo vast dat HSTS voor één jaar, of 31.536.000 seconden, het gebruik van HTTPS verplicht stelt.
File approver is een vorm van verificatie bij de uitgifte van een SSL certificaat. Dit houdt in dat er een klein bestandje op de server wordt geplaatst, dat door de Certificate Authority kan worden uitgelezen.
File approver kan alleen gebruikt worden via de API en alleen op de DV certificaten van Symantec, Thawte, GeoTrust, en RapidSSL. Deze vorm van verificatie komt in de plaats van e-mail verificatie.
De inhoud van het approver bestand wordt u toegestuurd in de response van de API. Kopieer deze tekst en sla het op in een bestandje met de naam 'verify.txt'.
Het file approver bestandje moet worden geüpload op de volgende locatie op de server:
Meer informatie over het gebruik van de file approver kunt u vinden in hoofdstuk 5.3 van onze API documentatie.
Wij zijn tijdens kantooruren telefonisch en via de chat bereikbaar.
