SSL Verschlüsselung einrichten...

Nunja - es gibt die professionelle und die "quick-and-dirty" Variante. Die Professionelle steht komplett in der Adminhilfe beschrieben, wenn du dich als Profi beim Kunden siehst solltest du diese Variante bevorzugen.

Die "quick-and-dirty"-Version ist die veraltete R5-Variante für selbstzertifizierte Keys und nur für HTTPS aber nicht für S/MIME einsetzbar, immerhin ausreichend um verschlüsselte Web Inhalte zu übertragen oder Passwort-Sniffer in der Leitung abzuhalten.

Die alte Variante funktioniert in kurzen Worten so:
- Eine DB auf Basis der Schablone Server Certificate Admin (csrv50.ntf) anlegen, Dateiname dabei egal, wird nicht mehr benötigt anschließend.
- Create Key-Ring with selfcertified Cerificate ausführen.
- Danach die beiden dabei im lokalen (!) Data-Verzeichnis erstellten selfcert.xxx Schlüsselringdateien ins Data des Servers verschieben.
- Im Serverdokument den Namen des Schlüssels im SSL-Bereich der HTTP Konfiguration eintragen und SSL aktivieren. Evtl. Authentifizierungen per HTTP abschalten (damit ein automatischer Wechsel bei der Anmeldung auf HTTPS stattfindet).
- HTTP einmal runter und wieder hochfahren (Achtung: bei R5 nicht tell HTTP restart machen - RedBox Panic).
- ggf. Datenbanken oder Anmeldemaske usw. anpassen

Thats all (dauert nicht mal 10 Minuten beinhaltet aber keine MIME [für Clients bzw. Mailverschlüsselung] oder Trusted Certificates [kostenpflichtig], daher quick & dirty).

Vor genau 2 Jahren und ein paar Tagen habe ich diese Quick & Dirty-Lösung für einen Server bei mir eingerichtet. Du kannst dir schon vorstellen, was "und ein paar Tagen" heißt. Seit ein paar Tagen lauscht der HTTP-Task nämlich nicht mehr auf den Port 443, weil das Zertifikat abgelaufen ist.

Und ich habe keine Ahnung, wie und wo man man dieses Zertifikat verlängern kann. Der selbstvertrauende CA-Certifier ist da.

Um den HTTP-Task auf einem 5er Server neu zu starten, nehme ich nie RESTART, sondern tell HTTP Quit und anschließend load HTTP. Damit habe ich noch nie Probleme gehabt.

Wenn du auch nicht weisst wie du es verlängerst - neu anlegen wäre kurz und schmerzlos und für HTTPS allemal ausreichend ;=)

Lieber Carsten,

der Tipp war Gold wert. Neuen Keyring erstellt - jetzt mit 5 Jahren Gültigkeit, den im Serverdokument eingetragen - und schon lauscht der HTTP-Task wieder auf Port 443 und alles klappt.

Tausend Dank - mein Problem ist gelöst - und ich glaube, das unseres Freundes mit der Anfrage auch.

Hallo,

ich hab die dirty Methode soeben bei mir ausprobiert und es hat wunderbar geklappt.
Nur ist der Schlüssel bei mir nur ein jahr gültig?

Wie kommst du auf 2 oder sogar fünf Jahre??

Greusse,
Christian

In den Konfigurationseinstellungen für Schlüsselringe (zweiter von 3 Hauptpunkten in der CA-DB) hinterlegst du, wie lange ein mit dieser Autorität erstellter Schlüssel Gültigkeit haben soll. Und da habe ich jetzt 5 Jahre eingetragen - und beim Erstellen des Keyrings hat er mir einen Keyring mit 5 Jahren Gültigkeit erzeugt.

Zitat

Trusted Certificates [kostenpflichtig]

das stimmt nicht so ganz! Es gibt von CACert kostenlose Zertifikate! Zwar ist das RootCert noch nicht in allen Browsern, aber die Jungs und Mädels habe diesen Punkt auf Platz 1 ihrer ToDo Liste!

Das ist doch eine völlig andere Baustelle. Hier geht es ja nicht um das Trusting gegenüber einem Dritten, von allen anerkannten, sondern um die Generierung eines selbstvertrauenden CA-Zertifikats, das dem Server Keyrings zur SSL-Verschlüsselung bereitstellt.

Und die Gültigkeitsdauer des mit einem selbstvertrauenden CA erstellten Keyrings kann ich einstellen.

Die Quick and Dirty Anleitung hat bei mir auch funktioniert. Jetzt hänge ich beim nächsten Schritt. Ich habe in der Server Certificate Administration einen neuen Schlüsselgeneriert und einen Request erzeugt. Da mein CA (besagte CACert) nicht von Haus aus im Domino ist, habe ich versucht im 3. Punkt das Root Cert zu installieren. Ich habe mir den Schlüssel auf der Homepage besorgt und per Past and Copy eingefügt. Domino erkennt auch das Certificate, da der Server mir vor dem Merg ja noch einmal alle Details anzeigt. Diese sind links und rechts identisch. Nur wenn ich okay klicke bekomme ich den Fehler "Certificate siganture does not match contents". Wo liegt der Fehler? Habe ich etwas falsch gemacht oder muss ich das Root Cert vorher noch im OS hinterlegen? Ich verzweifle daran schon ein paar Tage, besonder weil ich in diesem Punkt auch nicht aus der Hilfe schlau werde! :-?

Zitat

Erdnuckl schrieb:
...
Es gibt von CACert kostenlose Zertifikate! Zwar ist das RootCert noch nicht in allen Browsern, aber die Jungs und Mädels habe diesen Punkt auf Platz 1 ihrer ToDo Liste!

Ich muß zugeben daß mir CACert.org bis dato noch nicht untergekommen war. Also hab ich mir das mal ein wenig genauer angeschaut und dabei sind mir folgende Dinge (negativ) aufgefallen:

- als erstes sucht man auf der gesamten Website vergeblich nach einem Impressum mit Anschriften, Telefonnummern etc.
- eine WhoIs Anfrage liefert auch Erstaunliches, registriert wurde die Domain auf eine Privatperson (Duane Groth, auf der Website ist er als Präsident angegeben - einen entsprechenden Hinweis auf die kommerzielle oder non-profit Organisation sucht man aber vergeblich.)
- um ein echtes TrustCenter auf die Beine zu stellen benötigt es etwas mehr als nur 2 PC's in ein Rack zu packen, das Ganze wirkt auf mich nicht gerade vertrauenserweckend.
- da ich davon ausgehe daß vor der Integration des Root Certificates auch die Browserhersteller einige Nachforschungen und Audits vor Ort anstellen wollen kann ich mir nicht vorstellen daß das so bald passieren wird, das ganze Projekt wirkt (derzeit) zu laienhaft.

Ich war vor einigen Jahren mal bei IBM an einem Projekt beteiligt wo es um einen Dienstleister (ein Rechenzentrum) ging der als CA für Bürgerzertifikate auftreten wollte. In diesem Projekt habe ich auch so einiges gelernt was den tatsächlichen Umfang und Aufwand betrifft den man hierfür betreiben muß. Es geht um weitaus mehr als nur mal eben ein paar digitale Schlüssel zu generieren, das kann Hans Wurst auch.

Wer ein echtes (!) und anerkanntes Trustcenter aufziehen möchte muß sämtliche einschlägigen Vorschriften einhalten, regelmäßige Audits (von anerkannten Prüfgremien) über sich ergehen lassen, seine Technik entsprechend absichern (simples Besipiel - Desaster Recovery: Was passiert nach Brand, Diebstahl, kompromittierten Schlüsseln, wer verfügt über Passwörter, wie ist Vertreterregelung gelöst, wer hat physischen Zugang zur Technik, wer überwacht den Zugang, wer überwacht die Ablage der Backups, was passiert mit den generierten Privatschlüsseln wirklich und und und). Ist ja nett wenn die Jungs irgendwelche Quellcodes zum Prüfen anbieten - über die Vertrauenswürdigkeit und die Organisation besagt das nichts.

Alles in Allem sicher ein lobenswerter Ansatz - aber angesichts des zu betreibenden Aufwands kann ich mir kaum vorstellen daß das so alles funktioniert wie die Jungs sich das vorstellen. Es gibt auf den Internetseiten des BSI umfangreiche Dokumente und Linklisten, wenn man sich dort mal ein wenig umschaut dann versteht man warum echte und vertrauenswürdige Zertifikate derzeit nur kostenpflichtig erhältlich sind.

Aber vielleicht finden die Jungs auch irgendwann Sponsoren und ziehen alles etwas professioneller auf - dann wäre das sicher eine feine Sache. Bis dahin gilt für mich für CACert: Kostenlos? Ja. Vertrauenswürdig? Nein.

Zitat

Erdnuckl schrieb:
...
"Certificate siganture does not match contents"

Das bedeutet schlicht daß du das falsche Format benutzt (Notes kann nicht entschlüsseln und liefert daher diese Meldung). Um das richtige Format zu erhalten (BASE64 oder Binär) kann man z.B. mit einem Browser das Zertifikat öffnen und im für Notes lesbaren Format wieder exportieren (DER-codiert oder Base64-kodiert). Anschließend diese Datei nehmen. Die beiden Fensterhälften links und rechts zeigen NICHT das gleiche an - zu deiner Kontrolle. Allerdings scheitert diese Aktion anschließend daran, daß CACert kein Trusted Root Certificate darstellt, das wäre die nächste Fehlermeldung an der du scheitern wirst.

Carsten hat vorbildlich zusammengestellt, was im Umfeld einer öffentlichen Vertrauensstelle zusammenkommen muß, damit unterschiedliche Dritte einander vertrauen, wenn die Vertrauenswürdigkeit zueinander über eine solche Stelle gestiftet wird.

Es gibt keinen Notar, der für umme beurkundet - und deshalb kosten Schlüsselringe, deren Echtheit über eine Vertrauensstelle bestätigt wird, Geld, denn dahinter steckt eine echte Dienstleistung.

Erdnuckl möchte aber eine kleine, schnelle Lösung, in der nicht die Vertrauenswürdigkeit im Vordergrund steht, sondern die Verschlüsselung der übermittelten Daten.

Und dafür bietet Notes die Möglichkeit der Generierung eines selbstvertrauenden Zertifikats. In der CA-Datenbank gibt es drei Hauptpunkte (blau in der Mitte der Eingangsseite). Punkt 1 erstellt eine selbstvertrauende Zertifizierungsstelle, Punkt 2 erstellt die Vorgaben für die Schlüsselringe, die damit produziert werden und Punkt 3 erstellt Schlüsselringe, die dann sofort mit dem AdminP-Prozess eingerichtet werden.

Der Name des erstellten Schlüsselrings wird dann in das Serverdokument eingetragen - und fortan werden https-Requests damit verschlüsselt. Natürlich bekommt der Browserbenutzer bei seiner Anfrage ein Zertifikat präsentiert, dessen Echtheit er bestätigen muß.

Mhmm, dass mit den Unterschiedlichen Formaten hatte ich eigentlich schon probiert. Aber ich werde mir das noch einmal genauer ansehen. Aber Danke für den Hinweis. Jetzt weiss ich wenigstens woran es hapert und kann da noch einmal gezielter Vorgehen. Aus der Antwort entnehme ich, dass es keine Möglichkeit gibt CACert als Root zu akzeptieren, oder?

Da CACert momentan etwas "undurchsichtig" ist kann ich nicht abstreiten, was die akzetpanz angeht aber schon. In zB Knoppix, TheBat! sind die RootCerts schon integriert und Mozilla ist in Vorbereitung. Bis es aber über all drin ist wird es in der Tat noch eine ganze Weile dauern. Da wir aber nur eine kleine Firma sind, wäre das auch ein "kleines" Problem und außerdem musste ja jeder mal klein Anfangen.

Gruss

Erdnuckl

Hallo zusammen,

ich bin grad auf das Thema hier gestossen und habe einen Schlüsselring erstellt (für die quick & dirty methode)
Aber leider ist der nur 1 Jahr gültig. Und ich finde die beschriebene Einstellung nicht?

Wir verwenden Notes R5 gibt es die da auch?

gruesse,

Christian

In den Konfigurationseinstellungen für Schlüsselringe (zweiter von 3 Hauptpunkten in der CA-DB) hinterlegst du, wie lange ein mit dieser Autorität erstellter Schlüssel Gültigkeit haben soll. Und da habe ich jetzt 5 Jahre eingetragen - und beim Erstellen des Keyrings hat er mir einen Keyring mit 5 Jahren Gültigkeit erzeugt.

Den mit 1 Jahr Gültigkeit erstellten Schlüssel kannst du nicht verlängern, aber du kannst dir einen neuen generieren mit längerer Gültigkeit und den im Serverdokument eintragen.

Hm... ich habe den Server Zertifizierungsadmin (CA oder?)

da ist bei mir der zweite Hauptpunkt

Schlüsselringe anzeigen & bearbeiten

Bin ich da in der falschen DB?

Hi,

da Ihr Euch jetzt ja alle so prima mit SSL auskennt, kann ich ja nochmal eine etwas ältere Anfrage in die Runde werfen. Vielleicht hat ja jemand eine befriedigendere Aussage als IBM ...