Tag: SSL/TLS

  • Certificate Store voor SSL certificaten

    Certificate Store voor SSL certificaten

    Sinds Domino versie 12 is er weer een nieuwere methode om SSL certificaten te beheren binnen de Domino omgeving.
    HCL introduceerde daarvoor een nieuwe servertaak, Certificate Manager (CertMgr), die samenwerkt met een nieuwe database, Certificate Store (certstore.nsf), om de generatie van TLS-certificaten van de Let’s Encrypt-certificeringsinstantie (CA) en andere externe CA’s te automatiseren.
    CertMgr vereenvoudigt en beveiligt de werking van de Domino-webserver door automatisch gratis, breed vertrouwde TLS-certificaten aan te vragen, te configureren en te verlengen bij de Let’s Encrypt-certificeringsinstantie (CA) of een andere externe CA.

    In de Certificate Store kunnen ACME accounts, , DNS Providers en Configuaties, Trusted Roots, wachtwoorden en TLS Credentials worden ingesteld en opgeslagen.

    Gebruik van de Certificate Store Applicatie:

    De CertMgr-servertaak werkt met de Certificate Store-database (certstore.nsf) om certificaataanvragen en -beheer te vereenvoudigen. Als uw HCL Domino-server via uitgaande poort 443 en inkomende poort 80/443 met internet is verbonden, kunt u een certificaataanvraag genereren door (eenmalig) de volgende opdracht op de serverconsole uit te voeren:
    load certmgr -ACCEPT_TOU_AUTO_CONFIG

    (gelijk aan: load certmgr -r -c -o -y -ACCEPT_TOU )
    Met deze opdracht voert CertMgr de volgende stappen uit:
    Accepteert de gebruiksvoorwaarden voor de Let’s Encrypt®-certificeringsinstantie (-ACCEPT_TOU).
    Certstore.nsf wordt aangemaakt.
    De hostnaam van de machine wordt bepaald en een eerste certificaat wordt aangevraagd (-r).
    Het DSAPI-filter wordt geconfigureerd (-c).
    HTTP wordt gestart (-o) of HTTP wordt opnieuw gestart als deze al actief is (-c).
    Een certificaat wordt aangevraagd bij de Let’s Encrypt-certificeringsinstantie via het ACMEv2-protocol.
    Een .kyr-bestand wordt gegenereerd en op schijf opgeslagen.
    HTTP wordt opnieuw gestart om het .kyr-bestand te laden (-y).
    Ditzelfde certificaataanvraagscenario kan worden geautomatiseerd met behulp van de volgende notes.ini-instellingen:
    CertMgr_ACCEPT_TOU=1
    CertMgr_AutoRequestCert=1
    CertMgr_AutoConfig=1
    CertMgr_AutoConfigHttp=1
    CertMgr_RestartHttp=1

    Importeren

    Een eigen certificaat importeren in de TLS credentials van de Certificate Store kan natuurlijk ook.
    Zorg dan dat de hele certificaat keten uit bijvoorbeeld een PEM bestand formaat in een nieuw PEM bestand komt te staan met als eerste de tekst uit de private key. Noem dit bestand bijvoorbeeld fullchain.pem.

    —–BEGIN PRIVATE KEY—–
    ==content==
    —–END PRIVATE KEY—–
    —–BEGIN CERTIFICATE—–
    ==content==
    —–END CERTIFICATE—–
    —–BEGIN CERTIFICATE—–
    ==content==
    —–END CERTIFICATE—–

    Maak gebruik van een bestaande, of maak een nieuwe TLS credential in de Certificate Store.

    Importeer het eerder gemaakte gecombineerde bestand.

    Certificaat koppelen aan Website

    De TLS-cache zorgt voor het vinden van TLS-referenties. Het opzoeken kan via de DNS-naam, wat de nieuwe voorkeursmethode is. U vervangt dus de kyr-bestandsnaam door de DNS-naam. De nieuwe cache begrijpt ook KYR-bestandsnamen en gebruikt deze als tag voor het opzoeken.

    Maar dan moet in het TLS-referentiedocument de kyr-bestandsnaam zijn ingesteld (wat optioneel is in het TLS-referentiedocument en bedoeld is voor dit gebruik). De juiste manier is om altijd een DNS-naam op te geven. De nieuwe TLS-cache begrijpt DNS-namen, inclusief wildcard-certificaten, en ondersteunt meerdere SAN’s.

    Voorbeeld van een Web Site document:

    Met een bijbehorende  TLS referentie:

    Controle

    Door de certificaten met de Key file naam te vergelijken kan gecontroleerd worden of er een verband is tussen de TLS Credential en het Web Site document.

    tell certmgr show certs
    [19D0:0002-5264] Subject key identifier Key info Expiration KeyFile/Tag Host names (SANs)
    [19D0:0002-5264] ——————————————————————————————————————————————————
    [19D0:0002-5264] D5A9 FD93 2843 8506 … RSA 2048 88,6 days mrpowerzbook.ineco.nl
    [19D0:0002-5264] ——————————————————————————————————————————————————
    [19D0:0002-5264] 1 TLS Credentials

    tell http show security

    09-05-2025 22:56:17
    09-05-2025 22:56:17 Web Site: test (mrpowerzbook.ineco.nl)
    09-05-2025 22:56:17 SSL enabled
    09-05-2025 22:56:17 Key file name: c:\program files\hcl\domino12\data\mrpowerzbook.ineco.nl

    Dit laatste resultaat ziet er vreemd uit, maar negeer in dit geval het pad en kijk alleen of de hostname van het eerste resultaat gelijk is aan wat het bestand zou moeten zijn in het pad van het tweede resultaat. Dit is nog een kleine onvolkomendheid in de functie van HCL. In Dit geval is mrpowerzbook.ineco.nl gelijk in beide gevallen wat aangeeft dat het juiste certificaat is gekoppeld aan de website.

  • Apache of IIS als Reverse Proxy voor Domino

    Apache of IIS als Reverse Proxy voor Domino

    Gisteren bij een klant een Domino server voorzien van een wildcard SSL certificaat.
    Klant heeft meerdere (sub)domeinen maar slechts 1 publiek IP-adres.
    Voor sites draaiend op HTTP geen enkel probleem, maar zelfs in versie 9 van Domino is het nog steeds niet mogelijk om meerdere SSL sites op 1 IP-adres te configureren.
    Ik ben echt een groot liefhebber van IBM en Domino/Notes in het bijzonder, maar dat simpele dingen zoals dit nog steeds niet kunnen vind ik echt een misser!

    Notitie:

    De oplossing in dit bericht kan nog steeds werken, maar is met de komst van Domino V11.0.1 niet meer actueel: INECO – Vanaf HCL Domino V11.0.1 ondersteunt de Domino webserver Server Name Indication (SNI)

    Meestal plaats ik er dan maar een Apache HTTP of Microsoft Internet Information Services (IIS) server als Reverse Proxy voor (vaak op de zelfde machine), configureer de SSL sites en stuur ze intern door naar Domino via http op een andere poort, bijvoorbeeld poort 1080, zodat IIS of Apache op poort 80 een 443 kan draaien.
    In zowel Apache HTTP als IIS servers is het geen probleem om meerdere SSL/HTTPS sites aan 1 IP-adres te koppelen.

    IIS

    Voor IIS 8 ziet het er dan als volgt uit:
    iis_rewrite01

    iis_rewrite02
    iis_rewrite03

    iis_rewrite04

    Apache

    Voor Apache zijn er ook wel mooie interfaces, maar een tekstverwerker is snel en werkt ook prima:

    <VirtualHost *:80>
    ServerName demobedrijf.nl
    RewriteEngine On
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
    </VirtualHost>

    <VirtualHost *:443>
    ServerName demobedrijf.nl
    SSLEngine on
    SSLProtocol ALL -SSLv2 -SSLv3
    SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!RC4+RSA:+HIGH:+MEDIUM
    SSLCertificateFile “C:/Program Files/Apache/conf/ssl/star_ demobedrijf_nl.crt”
    SSLCertificateKeyFile “C:/Program Files/Apache/conf/ssl/star_ demobedrijf_nl.key”
    SSLCertificateChainFile “C:/Program Files/Apache/conf/ssl/Comodo_PositiveSSL_bundle.crt”
    ProxyPass / http://demobedrijf.nl:1080/
    ProxyPassReverse / http://demobedrijf.nl:1080/
    </VirtualHost>

    De webserver die als Proxy fungeert  luistert dan naar poort 80 en 443.
    iis_bindings

    En Domino staat ingesteld op  bijvoorbeeld poort 1080.

    domino_bindings

    Doordat de reverse proxy server intern via het gewone HTTP protocol verstuurd zal Domino geen probleem hebben om het juiste website document te koppelen aan het verzoek.

     

  • SSLException: Could not generate DH keypair

    SSLException: Could not generate DH keypair

    Bij een klant had ik een Domino agent gemaakt met behulp van Java om gegevens uit te wisselen tussen Domino en AccountView via https.

    Om dit goed te laten werken was Domino voorzien van de laatste JVM patches.

    Afgelopen week had de beheerder echter de server waarmee de agent verbinding maakte voorzien van een nieuw wildcard SSL certificaat met een hogere versleuteling.
    Hierna gaf de Java agent op de Domino server de volgende fout: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair.

    Policy bestanden

    Na wat zoeken op internet vond ik een artikel op de site van IBM waarbij gemeld werd dat de standaard JVM in Notes en Domino een restrictie hebben.

    Op de site van IBM kunnen tevens twee policy bestanden, local_policy.jar en US_export_policy.jar worden gedownload waar die restricties niet op zitten.

    Helaas bleek deze oplossing niet te werken bij de klant.

    Bouncy Castle

    Een ook bij de klant aanwezige software engineer had hiervoor echter wel een oplossing voor zijn softwarepakket dat ook voor Domino bleek te werken:

    Op de site https://www.bouncycastle.org/ hebben we het bestand bcprov-ext-jdk15on-153.jar gedownload. (De Bouncy Castle Crypto package is een Java-implementatie van cryptografische algoritmes)

    Vervolgens heb ik dit bestand in de map c:\IBM\Domino\JVM\lib\ext geplaatst.

    In de map c:\IBM\Domino\JVM\lib\security het bestand java.security  aangepast:
    security.provider.1=com.ibm.jsse2.IBMJSSEProvider2 veranderd in security.provider.10=com.ibm.jsse2.IBMJSSEProvider2.

    Vervolgens de regel security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider toegevoegd en het bestand opgeslagen.

    Na het herstarten van de Domino server werkte de agent weer.

    Fijn Harry (G), bedankt…

     

  • SSL (HTTPS) standaard voor www.ineco.nl

    Vanaf vandaag hebben wij onze website ook omgezet van http naar https (ssl).
    Steeds meer wordt deze veilige verbinding de standaard, vandaar dat wij ook niet achter willen blijven.

    SSL

    Met SSL wordt je (vertrouwelijke) informatie die tussen browser en server verzonden wordt versleuteld, zodat je gegevens niet onderschept kunnen worden.

  • Beveiligingslek in SSL 3.0 – ook van toepassing voor IBM Domino

    Beveiligingslek in SSL 3.0 – ook van toepassing voor IBM Domino

    Afgelopen week was het weer raak: diverse beveiliging sites waarschuwen voor een probleem met SSL (HTTPS verkeer).
    Zie bijvoorbeeld: www.security.nl
    Met POODLE (Padding Oracle On Downgraded Legacy Encryption) is een aanval via een SSL versie 3 verbinding mogelijk.

    SSL 3.0

    SSL 3.0 blijkt een forse fout te bevatten waardoor hackers toegang kunnen krijgen tot versleutelde informatie.
    Doordat het verouderde SSL 3.0 protocol ook in de nieuwe standaard, TLS, nog steeds beschikbaar is als terugval-optie, is de ‘Poodle’ bug ook voor nieuwe systemen een aanmerkelijk risico.

    Diverse software leveranciers zijn druk bezig met een oplossing voor dit probleem.
    Tot er een oplossing is wordt aanbevolen SSL2 en SSL3 uit te zetten op uw webserver en gebruik te maken van het veiligere TLS.
    Voor webservers als Apache is dit geen probleem, op internet zijn diverse manieren te vinden die dit helemaal uitleggen.
    Echter voor Domino servers met de standaard HTTP taak, is dit geen optie.

    De laatste versie van Domino, 9x Social Edition heeft ook de mogelijkheid om IBM HTTP Server als alternatieve webserver te gebruiken.
    Dit is al een hele verbetering omdat de IBM HTTP Server, gebaseerd op Apache, wel de veiligere verbindingen ondersteund.
    Met een paar aanpassingen (dezelfde als bij Apache) kan SSLv3 uitgeschakeld worden.
    Het installeren van IBM HTTP Server is een optie in het installatie programma van Domino 9. Zie ook http://www.ibm.com/support/docview.wss?uid=swg27039743
    Toch zijn ook met deze opzet diverse (andere) problemen gemeld op internet.
    IBM zelf heeft nog geen officiële reactie gegeven op dit probleem. Zie ook: Poodle SSL vulnerability – HCL Domino / Domino Forum – HCLSoftware Digital Solutions Community

    Apache reverse proxy

    Op dit moment lijkt het de meest betrouwbare oplossing om een Apache webserver te installeren die als reverse proxy wordt ingesteld om alle verzoeken door te sturen naar Domino.
    Dit kan, mits de server voldoende capaciteit heeft, op de zelfde machine geïnstalleerd worden zodat er geen extra hardware nodig is.
    De veilige SSL verbinding wordt dan tot stand gebracht met de Apache webserver die op zijn beurt intern een normale verbinding via HTTP met Domino maakt.
    Het voordeel is dat problemen met Apache veel sneller opgelost worden door de Open Source gemeenschap.
    Ten opzichte van de Domino HTTP server is certificaat beheer in IBM HTTP Server en Apache ook veel eenvoudiger.

    Microsoft IIS

    Voor Windows beheerders die liever met Microsoft IIS werken, natuurlijk is dat ook mogelijk in combinatie met IBM Domino.
    Op de site van Microsoft is ook informatie te vinden SSLv3 (en overige protocollen) uit te schakelen: http://support.microsoft.com/kb/187498/en-us

    Om te controleren of uw webserver kwetsbaar is zijn er diverse testen op internet te vinden, onder andere op:

    www.ssllabs.com
    ssltools.websecurity.symantec.com

    Vanzelfsprekend kunnen wij u helpen met het testen, adviseren en zo nodig het oplossen van dit probleem!

    Update 23 oktober 2014

    IBM heeft ook een Technote geplaatst over dit onderwerp:
    http://www.ibm.com/support/docview.wss?uid=swg21687167

    Zie ook:
    http://www.ibm.com/support/docview.wss?uid=swg21418982