WSO2-producten zijn te downloaden van de WSO2-website, een paar seconden later te installeren en klaar om te testen. Geen kosten, geen contracten en … geen juristen.
Als je dan een WSO2-product, opstart ontdek je dat de browser blijft steken op het certificaat dat gebruikt wordt om de verbinding te versleutelen. Dit is het zogenaamde ‘self-signed certificate’ en wordt gezien als minder veilig dan een certificaat van een gecertificeerde autoriteit.
Hoe werken certificaten?
Laat ik het kort en bondig uitleggen. Certificaten werken als een soort betrouwbaarheidsmechanisme. Ze worden uitgegeven door zogenoemde Certificaten Autoriteiten (CA), waaronder bedrijven zoals Comodo en Symantec. Als zijn een certificaat uitgegeven, dan is dat te vertrouwen, omdat de vertrouwensrelatie met de CA niet ter discussie staat. Het uitgegeven certificaat bevestigd dat deze site daadwerkelijk de site is die van de bijbehorende organisatie.
Dit soort certificaten worden gebruikt om https-verkeer van en naar je WSO2-producten te versleutelen en te beveiligen. Om HTTPS in te stellen zul je een geldig certificaat nodig hebben om het WSO2-product in te schakelen en de verbinding te versleutelen.
Ik heb voor deze tutorial een wildcard certificaat gebruikt dat ondertekend is door een (vertrouwde) Certificaten Autoriteit. Dit certificaat wordt gebruikt in plaats van het zelfgetekende WSO2-certificaat in de keystore. Dit werkt geweldig voor testen, maar in een productie-omgeving vervang je deze natuurlijk met een ander certificaat. En je voorkomt die vervelende berichten over veiligheid vanwege de zelfgetekende certificaten.
Besef je wel dat certificaten geld kosten, omdat je betaald voor een dienst die je aangeboden wordt (in dit geval vertrouwen). Er zijn enkele organisaties die gratis certificaten voor 90 dagen aanbieden. Dat is handig als het zou willen uitproberen en niet direct geld wilt besteden aan een volledig certificaat. Onthoud dat je daarvoor wel moet kunnen bewijzen dat je de eigenaar bent en controle hebt over de website waar je een certificaat voor aanvraagt. Voor meer informatie kun je op het internet terecht.
We gaan ervan uit dat je een werkend WSO2-product hebt (dus een WSO2 ESB). Voordat we beginnen wil ik eerst een paar dingen klaarzetten:
- Een geldig certificaat, normaliter te krijgen bij de systeemadministrator van een bedrijf
- De private key van het certificaat, meestal te krijgen bij de systeemadministrator van een bedrijf
- De basis- en tussencertificaten die aangeboden worden door het vertrouwde bedrijf dat het geldige certificaat ondertekend heeft.
Deze kunnen gedownload worden van de website van het bedrijf (In dit geval heb ik een comodo certificaat gebruikt: https://support.comodo.com/index.php?/Default/Knowledgebase/List/Index/108/sha-2)
Om uit te vinden welke je nodig hebt, zul het geldige certificaat moeten openen en daarna ook het onderstaande scherm.
Dit is het tabblad waarin je de certificatenketen kunt zien en je ziet nu dat het ‘clients wildcard certificate’ degene is die op dit moment geselecteerd is.
Boven het huidige certificaat staat nog twee andere certificaten. Dit zijn de tussencertificaten in de certificatenketen.
Als je ze selecteert, dan zie je de namen van de tussencertificaten die je nodig hebt:
- Comodo RSA Organization Validation Secure Server ca certificate
- Comodo RSA Certification Authority certificate
In het geval van het basiscertificaat staat deze niet in de lijst en is waarschijnlijk al geëmbed in het systeem dat je gebruikt. Als je het niet zeker weet, dan zou er niks mis moeten gaan als je deze ook toevoegt.
- Add Trust External ca root certificate
Hier kun je het getekende wildcard certificate (*.domain.nl) zien en daarnaast de twee tussencertificaten in de keten. Als je de tussencertificaten opent, krijg je de precieze naam te zien van het certificaat dat je nodig hebt.
Dus de tussencertificaten die we nodig hebben zijn het COMODO RSA Certification authority cert en het Comodo Rsa Organization Validation Secure Server ca.
Een nieuwe keystore maken en instellen
Het maken van een nieuwe keystore met een vertrouwde sleutel vereist de volgende stappen, die we vervolgens in detail uitwerken:
- Creëer een PKCS12/PFX-bestand
- Creëer de Keystore
- Exporteer een publieke sleutel van het JKS-bestand
- Voeg de Keystore en de publieke sleutel toe aan het product
- Voeg de publieke sleutel toe aan de Public Truststore
- Configureer het product zodat het de nieuwe Keystore gebruikt
- Voeg de tussencertificaten toe aan de Keystore.
- Klaar!
Voordat we de Keystore creëren, zullen we een .pfx-bestand moeten maken met de verzamelde certificaten en sleutel.
Stap 1 – Creëer een PKCS12/PFX-bestand
Als eerste zul je de certificaten naar PKCS12/PFX-formaat moeten exporteren. Gebruik waar nodig sterke wachtwoorden. We hebben een openssl-prompt voor dit deel van het proces gebruikt. Dat kun je openen in de opdrachtregel door “openssl” in te typen. Voor het genereren van een correct PFX-bestand heb je de volgende opdracht nodig. Als die correct uitgevoerd wordt, vraagt het twee keer om een wachtwoord. Vergeet welke wachtwoorden je opgeeft, want je gaat deze later nodig hebben!
openssl pkcs12 -export -in <customer valid certificate file>.crt -inkey <customer valid certficate file private key>.key -name "<alias for your pfx>" -certfile <additional certificate intermediary1> -certfile <additional certificate intermediary 2> -out <pfx keystore name>.pfx |
Het resultaat is een geldig pfx-bestand.
Stap 2 – Creëer de Keystore
We gaan nu het PKCS12/PFX-bestand naar een Java Keystore converteren met de volgende opdracht:
keytool -importkeystore -srckeystore <pkcs12/pfx file name>.pfx -srcstoretype pkcs12 -destkeystore <Keystore file name>.jks -deststoretype JKS |
Voor deze opdracht heb je een geldige JDK-installatie nodig, want de keytool zit in de JDK. Je kunt hem in de /bin map van de JDK vinden.
Als je via het opdrachtregelscherm de keytool niet kunt vinden, kan het zijn dat de variabele van je PATH-omgeving variable niet ingesteld is. Pas die variabele aan op je computer en voeg de locatie van de ‘jdk bin’ map eraan toe. Als dit goed ingesteld is, zou je de keytool vanuit iedere map op de computer moeten kunnen gebruiken. Wanneer je nu de opdracht opnieuw uitvoert, heb je een geldige Keystore!
Stap 3 – Exporteer een publieke sleutel vanuit het JKS-bestand
Behalve de Keystore is er ook een “Public truststore” in het WSO2-product en die hebben we nodig om daar de publieke sleutel van onze eigen Keystore aan toe te voegen.
Omdat we nog geen publieke sleutel hebben, zullen we deze vanuit de Keystore moeten exporteren.
keytool -export -alias "certificate alias" -keystore <mykeystore.jks> -file <public key name>.pem |
Zorg ervoor dat de alias hetzelfde is als degene die je voor je pfx-bestand gebruikt hebt.
Stap 4 – Voeg de Keystore en de publieke sleutel toe aan het product
Voordat we de Keystore en de publieke sleutel voor het WSO2-product kunnen configureren, zullen we de bestanden eerst in de <PRODUCT_HOME>/repository/resources/security map moeten zetten.
Als de bestanden op de juiste plek staan, kunnen we het product zo configureren dat het de nieuw aangemaakte bestanden gebruikt.
Stap 4.a – Voeg de publieke sleutel toe aan de Public Truststore
De Public Truststore in de <PRODUCT_HOME>/repository/resources/security/ map heet “client-truststore.jks”. Met de onderstaande opdracht voegen we de publieke sleutel toe aan deze Truststore.
keytool -import -alias <certificate alias> -file <public key name>.pem -keystore client-truststore.jks -storepass wso2carbon |
Let op: het standaard wachtwoord voor de client-truststore.jks is “wso2carbon”.
Stap 4.b – Configureer het product zodat het de nieuwe keystore gebruikt
Ieder WSO2-product bevat verschillende bestanden die naar de default keystore verwijzen. Als je deze wilt vervangen met een nieuwe, dan zul je de registratie op alle plaatsen die daarop betrekking hebben moeten vervangen.
Het belangrijkste bestand om te configureren is de registratie van de primaire keystore in het <PRODUCT_HOME>/repository/conf/carbon.xml bestand. Als je deze registratie niet wilt veranderen, kun je ook handmatig een extra registratie toevoegen.
De registratie ziet er zo uit:
|
|
En voor het wijzigen werkt zoiets als dit:
<KeyStore> |
Let op dat het wachtwoord als gewone tekst opgeslagen wordt. Als je een veiligere placeholder met een versleutelde waarde op zou willen slaan, gebruik dan SecureVault. Voor meer informatie over dit onderwerp kun je deze blog van mijn collega lezen:
De makkelijkste manier om alle registraties van de default keystore te vinden is door “grep -nr “.jks” als zoekopdracht te gebruiken in de <PRODUCT_HOME>/repository/conf/ folder. Hiermee worden alle relevante registraties en bestanden eruit gefilterd.
Dat ziet er uit zoals hieronder afgebeeld. Je kunt nu ieder bestand openen, de plekken vinden waar de registraties van de Keystore staan en die vervangen.
/axis2/axis2.xml:260: <Location>repository/resources/security/wso2carbon.jks</Location> |
Wanneer je deze registraties vervangen hebt, start je de server opnieuw op.
Stap 5 – Voeg de tussencertificaten toe aan de Keystore.
Nu dit correct geconfigureerd is, zoeken we de Keystore op in de carbon console.
Onder het tabblad ‘Main’ staat een knop met de naam “Keystores”. Hier zou je eerst de “wso2carbon.jks” hebben zien staan, maar deze bevat nu jouw eigen Keystore.
Als dit niet het geval is, controleer dan of de configuratie van de keystore registratie in the carbon.xml juist is.
Het ziet er zo uit met de naam van jouw Keystore.
We hoeven nu alleen nog de tussencertificaten en (optioneel) het basiscertificaat aan de keystore toe te voegen.
Klik op de ‘Import cert’-knop en doe dit ook voor de tussencertificaten.
Uiteindelijk ziet het er dan ongeveer zo uit:
Stap 6 – Klaar!
Herstart de server en ga naar de carbon console. In je browser, naast de URL, kun je zien of je verbinding een valide HTTPS-verbinding is.
Als er nog steeds staat dat de website onveilig is, dan kun je in je browser extra informatie over het probleem opvragen door op de notificatie te klikken.
Als je daar niet genoeg details krijgt, dan kun je ook één van de vele beschikbare SSL-checker webtools gebruiken, zoals https://www.ssllabs.com/ssltest/.
Let op: als je direct naar het IP-adres in je browser gaat, en niet via een DNS-adres, dan krijg je als resultaat dat de HTTPS incorrect is. Dit komt omdat we in ons geval een certificaat gebruikt hebben dat uitgegeven is voor *.domain.nl, dus de browser registreert de website alleen als veilige website wanneer je via een variatie van *.domain.nl binnenkomt.
Als je vragen hebt over deze blogpost, neem dan contact met ons op via het commentaar onder deze blog. Bekijk ook onze WSO2 Tutorials, webinars en whitepapers voor meer technische informatie. Ben je op zoek naar ondersteuning? We bieden WSO2 Productondersteuning, WSO2 Development Support, WSO2 Operational Support en WSO2 Trainingsprogramma’s.
Met dank aan Rob Blaauboer voor zijn bijdrage aan deze blog.
