SSL-Zertifikate für Domino-Web-Server sind leicht zu erstellen, insbesondere, wenn es sich um selbst-zertifizierte Zertifikate handelt:

• Erstelle eine Datenbank aus der Schablone "StdNotes50SSLAdmin" (certsrv.ntf),
• öffne sie,
• klicke auf "Create Key Ring with Self-Certified Certificate",
• fülle das Formular aus,
• kopiere die erstellten Dateien auf den Domino-Server und
• aktualisiere das entsprechende Server-Dokument, so dass es auf die neuen Dateien zeigt.

Das
war's. Selbst-zertifizierte SSL-Zertifikate sind günstig (keine Kosten
aus deiner Arbeitszeit), aber sie können nicht verifiziert werden mit den
vorinstallierten Wurzelzertifikaten von Firmen wie Verisign.

Deshalb wird diese Art von SSL-Zertifikaten
häufig nur für interne Web-Server eingesetzt. Aber mit dem Erscheinen von
Lotus Notes Traveler haben diese Zertifikate eine wahre Renaissance erlebt.



Aber es gibt ein Problem: Die
so erstellten Zertifikate sind nur für genau ein Jahr nach Erstellung
gültig. Es gibt keine Möglichkeit, sie anders zu erstellen, oder vorhandene
zu verlängern.

Das bedeutet, dass wenn man selbst-zertifizierte
SSL-Zertifikate für einen Lotus Notes Traveler-Server benutzt, dann muss
man sie jährlich durch neue ersetzen und jeder Benutzer erhält jedes Mal
eine Warnung.



Aber wie (fast) immer bei Lotus Notes
und Domino gibt es einen Weg, das Ziel doch noch einfach zu erreichen...

Wenn man sich den Code hinter dem "Create Key Ring with Self-Certified Certificate"-Button in der "CertAdminCreateKeyringWithSelfCert"-Maske genauer ansieht, findet man schnell heraus, dass der kritische Teil des Codes sich in einer C-Funktion namens ProcessSecurityCmd in der dmsecadm.dll befindet:

"CertAdminCreateKeyringWithSelfCert" -Maske mit Button

Declare Function ProcessSecurityCmd Lib "_dmsecadm" (Byval cmdName As String, Byval cmdArgs As Lmbcs String, Byval OutBuf As String, Byval szOutBuf As Integer) As Integer

Ich habe nirgends irgendeine Dokumentation zu dieser Funktion oder zu der DLL-Datei gefunden.

Alle Argumente für diese Funktion werden vor dem Aufruf gesammelt und in einem String zusammengefasst:: cmdArgs.

Nachdem ich mit Strings einmal ganz tief in diese DLL-Datei abgetaucht bin, konnte ich einen möglichen Parameternamen finden, der danach klingt, dass man damit die Gültigkeitslänge des Zertifikats in Tagen angeben könnte: ValidDays

Zum Ausprobieren habe ich diesen Parameter dem cmdArgs-String hinzugefügt:

Anpassung des Codes im Button

Ich habe den folgenden Code direkt unterhalb der Initialisierung des cmdArgs-Strings eingefügt:
'<modified author="Thomas Bahn <tbahn@assono.de>" timestamp="2012-07-31"
' description="change how long the certificate is valid (in days); 7305 means: 20 years">
CmdArgs = CmdArgs & "ValidDays=7305;"
'</modifed>

Für diesen Test habe ich den Wert fest auf 7305 Tage, also exakt 20 Jahre gesetzt. Man könnte aber auch ganz einfach dafür ein Feld in der Maske ergänzen und dessen Wert verwenden.

Dann habe ich einen neuen Schlüsselring erzeugt:


Das folgende Dialog-Fenster lügt einfach. Das Enddatum ist immer genau ein Jahr von heute (Werteformel: @Adjust( @Today;1;0;0;0;0;0)):


Um das erstellte Zertifikat zu überprüfen, navigiere zu "View & Edit Key Rings",


klicke auf "Select Key Ring to Display",


gebe den Namen der Schlüsselring-Datei ein,


gebe dass Passwort ein und


öffne das Site Certificates - KeyPair-Dokument.


Am Ende des Dokuments steht die echte Gültigkeit aus dem Zertifikat und - Hurra! - es sind wirklich 20 Jahre: