Een klant had een raar probleem. Een database waar documenten een volgnummer kregen bij het aanmaken, bleek ineens dubbele nummers te krijgen.
Waar de nummering eerder nog iets in de 18 miljoen was, begon het ineens weer met 16.877.210. En dat herhaalde zich een paar keer.
Na inspectie van de code bleek de teller bijgehouden te worden in een document. Niet ongebruikelijk, de code klopte ook, en werkte nog steeds goed.
Maar deze database had ook een replica. Ondanks dat de teller slechts in een database werd gebruikt leek Notes bij het repliceren toch telkens overtuigd dat de replica met het oudere teller document nieuwer was dan de bron database, die wel degelijk nieuwer was.
Na controle van het replica id hadden we het over het volgnummer dat Notes gebruikt om samen met de datum te bepalen welk document in een replica nieuwer is.
Een collega Notes specialist die goed met cijfers is zag direct wat het was: de nummering in het volgnummer (sequence number) kan bestaan uit maximaal FFFFFF. Dit is gelijk aan 16.777.215, en daarna begint het tellen weer bij 0.
In ons geval was het nummer in de originele database dus over de FFFFFF heen gegaan, en had daarmee een lager nummer gekregen dan het replica document, waardoor telkens bij het repliceren het oudere document weer terug werd gerepliceerd waardoor ook de teller voor de documenten weer lager was.
Door een nieuw teller document aan te maken was het probleem weer opgelost, maar dit was wel de eerste keer dat ik dit zag in een Notes database.
Leuk die theorie, maar waarom staat het volgnummer bij een nieuw document dan op 00000001 (8 posities), wat in mijn ogen aangeeft dat het tot FFFFFFFF (4.294.967.295) kan gaan en niet tot FFFFFF?
Dat antwoord kan ik helaas (nog) niet geven, maar een korte test met een code loopje gaf uitsluitsel, na 00FFFFFF begon het nummer weer met 00000001. Of dit een bug is of een bewuste keuze durf ik niet te zeggen.
Even wat uitleg over het sequence number:
Als database A een document bevat met een bepaalde UNID en database B bevat een document met het zelfde UNID, zal de replicator concluderen dat deze twee documenten replica kopieën van elkaar zijn.
In dat geval, gaat de replicator verder met het volgnummer en sequentietijd van de twee documenten te onderzoeken.
Als het volgnummer en de tijd van aanpassing het zelfde zijn voor beide documenten , dan is er volgens de replicator geen actie vereist omdat de documenten gelijk zijn aan elkaar.
Aan de andere kant, als een van beide, het volgnummer of de tijd van aanpassing, of beide, verschillen tussen de twee documenten, dan moet de replicator beslissen welke recenter is en het oudere document actualiseren met de inhoud van de meest recente versie.
Als een document is bijgewerkt maar het andere document niet, wordt het sequentienummer van het eerste document groter dan die van het andere document.
De replicator behandelt deze zaak door het overschrijven van het andere document met de eerste, waardoor de twee databases weer synchroon zijn.
Universal Note ID (UNID)=
OF162EE8B9:66439054
ON2BAE1447:A7A43567
SDC1257F8F:0067AAFF-SN00000001
DBC1257738:002ED95E
NT00096E86
Sequence Time =
OF162EE8B9:66439054
ON2BAE1447:A7A43567
SDC1257F8F:0067AAFF-SN00000001
DBC1257738:002ED95E
NT00096E86
Sequence Number =
OF162EE8B9:66439054
ON2BAE1447:A7A43567
SDC1257F8F:0067AAFF-SN00000001
DBC1257738:002ED95E
NT00096E86
De overige regels zijn: Originator ID (OID) =
OF162EE8B9:66439054
ON2BAE1447:A7A43567
SDC1257F8F:0067AAFF-SN00000001
DBC1257738:002ED95E
NT00096E86
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.
Om een aantal voorkeuren in de IBM Verse app voor Apple devices te kunnen instellen via een Policy document op de Traveler server heeft IBM een aangepast adresboek (pubnames.ntf) beschikbaar gesteld.
Dit sjabloon is te vinden op de site van IBM: http://www.ibm.com/support/docview.wss?uid=swg21699618
Een directe link naar het Engelstalige (zip) bestand: ftp://public.dhe.ibm.com/software/lotus/fixes/NotesTraveler/English_pubnamesNTF_Traveler_Verse.zip
Wanneer je een “set config” commando op de Domino server console uitvoert, bijvoorbeeld “set config server_restricted=2”, om de waarde van een bestaande notes.ini parameter aan te passen, wordt de parameter in het configuratie document niet aangepast.
Hierdoor wordt het console commando na een tijdje weer overschreven door de instelling in het configuratie document.
Wil je dit aanpassen zodat een console commando het configuratie document bijwerkt kan de volgende regel in de notes.ini van de server worden toegevoegd:
In eerdere berichten gaf IBM aan voorlopig geen oplossing te hebben voor de Domino HTTP server en het Poodle attack probleem. Nu zijn er sinds 5 november toch Interim Fixes uitgebracht voor Domino 8.5.1 FP5, 8.5.2 FP4, 8.5.3 FP6, 9.0 en 9.0.1FP2.
Hoe wordt IBM Domino beïnvloed door de POODLE aanval ?
SSLv3 bevat een kwetsbaarheid die is aangeduid als de Padding Oracle On Downgraded Legacy Encryption (POODLE) aanval. Dit is een zogeheten man-in-the-middle-attack die webbrowsers kwetsbaar maken. Browsers verbinden via SSLv3 naar Domino servers over HTTP en kunnen zo worden blootgesteld aan de POODLE aanval. Een oplossing zou zijn om SSLv3 in de browser uit te schakelen. Als dit echter in de browsers uitgeschakeld wordt zal er geen verbinding meer mogelijk zijn met de Domino servers omdat tot nu toe SSLv3 het enige beveiligingsprotocol is dat Domino servers ondersteunen.
IBM heeft nu dus de Interim Fixes voor Domino, die TLS 1.0 implementeert met TLS_FALLBACK_SCSV om HTTP te beschermen tegen de POODLE aanval, vrijgegeven. TLS 1.0 voor Domino is de bescherming tegen de POODLE aanval en maakt het mogelijk om browsers die ingesteld zijn om geen SSLv3 te gebruiken toch met Domino te verbinden.
Meer informatie vind je op http://www.ibm.com/support/docview.wss?uid=swg21687167
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:
Bij een update van IBM Notes 8.5.3 naar 9.01 FP2 bij een klant kreeg iedereen de standaard Ontdekken pagina te zien. Geen probleem natuurlijk, weg klikken en je kunt weer verder. Toch leek het handig om dit in de Desktop policy Setting aan te passen. Op het Basis tabblad staat een instelling bij Home Page Options voor Social Edition Options. Daar aangegeven niets te tonen. Bij Discover Page Options ook de keuze “Do not show” gemaakt. Instellingen opgeslagen, en ja hoor iedereen kreeg de Ontdekken pagina in beeld, en bleef die ook krijgen. In de notes.ini was de regel $DISCOVER_HOMEPAGE=2 toegevoegd door deze aanpassing. Nu las ik op de Developerworks pagina van IBM een tip om dan een Custom setting te maken in de Desktop Policy Setting om die regel de waarde 0 te geven. Nou vergeet het maar…. Zeg maar nee dan krijg je er twee in dit geval.
Er was zelfs een APAR bij IBM te vinden met dit probleem, en de oplossing was helder: de gebruiker begreep het niet of had een fout gemaakt….. Welke, wat en hoe?
Na wat zoekwerk blijkt er wel degelijk een fout te zitten in het Desktop Settings formulier. Paul McBride heeft op 10 juli 2014 ook de oplossing die hij van IBM had gekregen na het aanmelden van een incident beschreven. Voor die mensen die van plaatjes houden heb ik een paar schermafdrukken gemaakt van de aanpassingen die IBM voor versie 9.0.2 (eerste kwartaal 2015) zal maken.
Open het database sjabloon pubnames.ntf met de IBM Domino Designer.
Open het Policy Settings\Desktop Settings formulier.
Verander op het Basics tabblad de formule voor het veld $Pref$DISCOVER_HOMEPAGE$HA in @If(SocEdHome=”2″ & SocEdHome$HA!=”1″;””;tmpDISCOVER_HOMEPAGE$HA)
Verander de input translation formule van het veld $Pref$DISCOVER_HOMEPAGEin tmpOut:=@If((SocEdHome=”0″ | SocEdHome=””) & tmpDISCOVER_HOMEPAGE=”5″;”5″;SocEdHome=”2″ & SocEdHome$HA!=”1″ ;”4″;”2″); @If(tmpOut=””;”2″;tmpOut)
Verander de eigenschappen van het veld $Pref$DISCOVER_HOMEPAGE zo dat in plaats van een Checkbox een Dialog list wordt getoond, en haal het vinkje weg bij “Allow multiple values”.
Er staan nu een aantal velden in de tabel onder Discover page: pas om het netjes te maken de “Hide When” formules zo aan dat deze ook verborgen worden als de waarde van het veld SocEdHome”2” is. Een voorbeeld SocEdHome=”1” moet SocEdHome=”1″:”2” worden.
Sla het formulier op.
Vernieuw het ontwerp van names.nsf met het aangepaste sjabloon
Ga naar de desktop policy setting, bewerk dit document en sla het op.
Nu zou de Ontdekken pagina niet meer getoond mogen worden.
Het wil nog wel eens voorkomen dat je een bestaand SSL certificaat hebt en deze wil gaan gebruiken op je Domino HTTP Server. Een eenvoudige oplossing is natuurlijk om voor de Domino server een Apache of IIS webserver te installeren en SSL verzoeken via een proxy regel door te sturen naar Domino zonder SSL, dan is de hele oefening om een certificaat in Domino te krijgen helemaal niet nodig. Alleen kan deze oplossing niet overal gebruikt worden, of wil men deze niet gebruiken.
Dan zit er niets anders op dan of via de Domino Certificate Admin applicatie een nieuw certificaat aan te vragen bij een provider (vaak gratis binnen een bepaalde periode), of om een bestaand certificaat om te zetten.
Het aanvragen van een certificaat via de Notes applicatie is een standaard procedure die goed beschreven staat in de Administrator Help, en vaak ook bij de leveranciers van SSL certificaten, het omzetten van een Apache of IIS certificaat of importen van een wilcard certificaat is echter niet beschreven en is net iets lastiger.
Er zijn verschillende methodes waarvan ik er hier een beschrijf.
Open de Server Certificate Administration applicatie (certsrv.nsf), of maak deze aan met gebruik van het certsrv.ntf sjabloon.
Klik vervolgens op Create Key Ring.
Vul in het “Create Key Ring” scherm alle velden in zodat deze overeen komen met het certificaat dat je wil gaan gebruiken. Klik vervolgens op de knop “Create Key Ring” onderaan de pagina.
Als alles goed gegaan is komt er een dialoog met het resultaat.
Klik OK en kijk vervolgens of het sleutel paar in de opgegeven map staat.
Tot zo ver is het nog allemaal standaard. Nu gaan we echter geen “Certificate Request” indienen, want dat hebben we al…. We verlaten Notes nu even.
Stap 2.
Om in stap 3 de certificaten (het persoonlijk certificaat, het root- en eventuele intermediate certificaten goed te kunnen importeren moeten we precies weten wat de namen van de certificaten zijn. Als er geen duidelijke beschrijving mee geleverd is kunnen we de certificaten het beste openen in een internet browser zoals Internet Explorer. In het voorbeeld een oudere versie in Microsoft Windows XP.
Er zijn verschillende manier van certificaat uitgifte, de ene leverancier stuurt losse bestanden, de andere slechts een bestand waar de overige certificaten in zitten (de hele reeks of chain). In dit voorbeeld heeft een klant 1 bestand met de extensie pfx. Start Internet Explorer, klik op Extra > Internet opties > Inhoud.
Klik op de knop Certificaten.
In het venster Certificaten klik je op Importeren.
Klik op volgende en selecteer Bladeren.
Blader naar de map waar de SSL certificaten staan. Verander eventueel bij Bestandstypen de juiste extensie. In ons geval hebben we de klantnaam even aangepast naar wildcard.demo.pfx, dit zal normaal iets zijn als *.uwbedrijfsnaam.pfx.
Open het bestand.
Klik op volgende.
Geeft het wachtwoord op dat bij de sleutel hoort en zet eventueel een vinkje bij “Deze sleutel als exporteerbaar aanmerken.” en klik op volgende.
Klik op volgende of pas eerst de archief locatie aan indien deze niet goed staat.
Controleer de inhoud en klik op Voltooien. Als het goed is komt er een melding dat het importeren voltooid is. Klik daar op OK.
Als het goed is zal in het venster Persoonlijk uw certificaat staan. In ons geval is de klantnaam doorgestreept.
Mocht je nu niet een bestand hebben maar losse bestanden dan kan elk bestand geïmporteerd worden. Vaak hebben de root en intermediate certificaten geen wachtwoord, maar de routine is bijna gelijk aan de hier beschreven procedure.
Nu de certificaten in de browser zichtbaar zijn kunnen we kijken hoe de keten er uit ziet en de namen van de labels noteren.
Klik op Weergeven.
In het Certificaat venster klik je op Certificeringspad. Daar kun je zien dat er naast het root certificaat nog een intermediate certificaat aanwezig is. Ook is zichtbaar dat wij het root certificaat nog moeten importeren, maar dat is voor nu niet belangrijk.
Klik op het bovenste certificaat pad en klik op de knop “Certificaat weergeven”.
Noteer de naam achter het label “Verleend aan:”, in dit geval “AddTrust External CA Root” en klik op OK.
Doe dit voor de overige certificeringspaden ook tot aan de laatste regel. In ons geval komt er dus nog een naam bij, “PositiveSSL CA 2”
Deze gegevens hebben wij nodig om bij stap 3 in te vullen.
Mocht het nodig zijn dan kan er vanuit het certificaten venster ook een export gemaakt worden van de certificaten. In ons geval is dit niet nodig dus slaan we deze stap over en gaan naar stap 3.
Stap 3.
Om het bestaande certificaat toe te voegen aan het kyr bestand gebruiken we het programma ikeyman van IBM, o.a. te vinden op ftp://ftp.software.ibm.com/software/lotus/tools/Domino/gsk5-ikeyman.zip. Dit programma werkt het meest eenvoudig op een 32bits Windows XP omgeving, hoewel er op internet ook meldingen zijn van mensen die het aan de praat hebben gekregen met nieuwere versies van Windows met een oude Java omgeving. Voor deze beschrijving heb ik echter een Windows XP machine gemaakt in VMWare Player. Pak het bestand gsk5-ikeyman.zip uit. Open vervolgens een commando prompt (dos venster). Navigeer op de prompt naar de map waar je de ikeyman bestanden hebt uitgepakt. In de map staan twee batch bestanden. De eerste is om de paden aan de omgevings-variabelen van Windows toe te voegen. Type hiervoor de opdracht “gskregmod.bat Add” (zonder aanhalingstekens in) en enter.
Type vervolgens “runikeyman.bat” om IBM Sleutelbeheer te starten.
Als het goed is start IBM sleutelbeheer op:
Kies in het menu voor sleuteldatabase openen en navigeer naar het *.key bestand dat je hebt aangemaakt in stap 1.
Type het wachtwoord dat in stap 1 is ingevoerd voor het Sleutelring bestand.
Klik in het hoofdvenster onder het kopje Inhoud sleuteldatabase op het keuzeveld en kies “Certificaten van certificaatgever”.
Je ziet in het venster de certificaten die in het kyr bestand staan dat we hebben aangemaakt in stap 1. Waarschijnlijk staan de certificaten die we in stap 2 genoteerd hebben hier niet bij, en zullen we deze nu moeten toevoegen. Klik daarvoor op de “Toevoegen” knop.
Kies in het toevoegen venster op het juiste gegevenstype, in ons geval hebben wij *.CER bestanden van de leverancier gekregen en kiezen we voor “Binaire DER-gegevens”. Blader naar de locatie van de certificaten en klik op OK. In ons voorbeeld importeren we het root certificaat van AddTrust.
In het volgende venster hebben we dan de naam nodig die wij in stap 2 genoteerd hebben. Het is belangrijk om dit exact over te nemen.
Klik op OK. Doe het zelfde voor de eventuele intermediate certificaten. Het resultaat is zichtbaar in het venster van IBM Sleutelbeheer:
Als laatste moeten wij nog het persoonlijke certificaat toevoegen. Klik daarvoor in IBM Sleutelbeheer op het meerkeuzevak onder Inhoud sleuteldatabase op “Persoonlijke certificaten” en klik op de knop “Importeren”. Navigeer in het “Sleutel importeren” dialoog venster naar het persoonlijke certificaat. In ons geval was het certificaat niet zichtbaar in het bladervenster omdat bij bestandsnaam *.p12 stond. Dit is echter weg te halen zodat wel alle bestanden zichtbaar worden en wij het “wildcard.demo.nl.pfx” sleutelbestand kunnen kiezen.
Klik op OK. Ook hier wordt weer gevraagd om het wachtwoord van de sleutel. Vul dit in en klik op OK. Wanneer alles goed is gegaan ze je in het venster het certificaat dat net is ingevoerd.
Sla het sleutelbestand op als Sleutelringbestand (*.kyr), overschrijf daarbij het eerder aangemaakt sleutelbestand. Er wordt gevraagd een wachtwoord in te voeren, en eventueel kan de geldigheidstermijn daarvan ingesteld worden.
Klik OK, deze stap is daarmee afgerond.
Stap 4.
Wij hebben in de voorgaande stappen een sleutelpaar aangemaakt, en de certificaten toegevoegd. Om zeker te zijn dat Domino de sleutels kan lezen kunnen we deze nogmaals openen in IBM Notes met de “Server Certificate Admin”.
Klik daarvoor in link in het menu op “View & Edit Key Rings” Kies boven in het menu voor de knop “Select Key Ring to Display”
Type het volledige pad in naar het sleutelringbestand dat we in de eerdere stappen hebben gemaakt en aangepast. Geef het wachtwoord in en klik OK. Als alles goed is gegaan zien we nu bij Site Certificates een KeyPair en ons persoonlijke certificaat. Bij Certificate Authorities moeten het root- en intermediate certificaten staan die we eerder hebben geïmporteerd.
Als dit klopt kunnen we het *.kyr en bijbehorend *.sth bestand kopiëren naar de data map van de Domino Server.
In de configuratie van de Domino server dient de naam van het sleutelbestand natuurlijk overeen te komen met de bestandsnaam, maar als je al zo ver bent gekomen zal dat geen probleem mogen opleveren.
Herstart de HTTP taak en als het goed is heb je een werkend SSL certificaat. Controleer dit eventueel door op de Domino console het commando “Tell HTTP show security” in te geven.
Mocht je er ondanks deze instructies niet uitkomen kun je altijd contact met ons opnemen. Of plaats je reactie onder dit bericht.
Een klant had een probleem waarbij Notes 9.01 op een Windows 2012 (RES) Server niet meer geïnstalleerd kon worden. De installatie stopte op het moment dat daadwerkelijk installatie zou starten met een melding dat de “Installation interrupted” was.
De gebruikelijke stappen van het opschonen van het register en het verwijderen van mappen, stoppen van services en herstarten van de server e.d. hielpen niet.
Na wat zoekwerk zag ik in de Admin Help van versie 9 dat IBM gewoon een tooltje in de installatie map van Notes heeft staan om een vorige installatie netjes op te ruimen:
U kunt het programma InstallCleanupExecutable(NICE) gebruiken om na een mislukteNotes installatie of upgrade de computer op te schonen. U kunt ookgebruik maken van detool om eenbestaande versie vanNotes te verwijderen enoverbodigebestanden op te ruimen, vóórhet uitvoeren van een nieuwe installatie of upgrade. De toolis beschikbaar voorLotus Notes6.xenhoger. Installaties opondersteundeWindows-platformsenmoet worden uitgevoerddoor een beheerder.
In ons geval werkte de installatie direct na het uitvoeren van NICE!