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:
