Eigene CA, Zertifikate, Pfade

Alles rund um sicherheitsrelevante Fragen und Probleme.
Antworten
scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Eigene CA, Zertifikate, Pfade

Beitrag von scientific » 01.08.2017 11:19:29

Hi Leute!

Ich experimentiere wieder einmal damit herum, meinen Mail- und Webserver von außen zugänglich zu machen, das aber möglichst sicher.

Derzeit hab ich nur den SSH-Port weitergeleitet, und in dem tunnle ich die Ports für Web und Mail auf den Rechner, auf dem ssh oder Putty läuft.
Soviel zum Rundherum.

Ich möchte im Endeffekt die Ports 587 und 993 nach außen durchreichen, und den Mailserver per STARTTLS gesichert erreichbar machen.
Den Mailserver (exim und dovecot) hab ich derzeit schon so konfiguriert, dass er ausschließlich (START)TLS-gesicherte Verbindungen akzeptiert, und diese authentifiziert (ESMTP).
Ungesicherte und nicht authentifizierte Kontaktversuche werden abgewiesen. Das funktioniert bereits in LAN und per Port-Weiterleitung.

Ich habe mir mit exim-gencert (hab das nach /usr/local/bin kopiert und an meine Gegebenheiten angepasst) ein Zertifikat erstellt. Thunderbird auf localhost und auf einem anderen Rechner im LAN meckert zwar, dass das Zertifikat nicht verifiziert werden kann, aber ich kann eine Ausnahme erlauben. Dann klappt es.
Jetzt hab ich versucht, auf mein Handy die beiden Ports mit Juicyssh weiterzuleiten und mit der Gmail-App den Mailserver zu erreichen.
Die Verbindung klappt, das Zertifikat kann aber nicht überprüft werden, da keine CA im Speicher vertrauenswürdiger CAs vorhanden ist - und Gmail-App verweigert solche Verbindungen. Eh klar. Hab ja keine.

Stimmt nicht ganz. Ich hab das schon mal geschafft, selber eine CA zu erstellen, dann Zertifikate damit zu signieren und das CA-Zertifikat auf das Handy zu laden. Damit klappte dann auch die Verbindung. Aber mein Zertifikat ist abgelaufen, und ich finde die Anleitung nicht mehr, mit der ich mir damals sowohl CA als auch Zertifikate für exim als auch dovecot gebaut habe... Und so muss ich wieder von vorne anfangen.

Ich habe zwei Anleitungen gefunden, die für mich vielversprechend aussehen:
https://datacenteroverlords.com/2012/03 ... authority/
http://www.wikihow.com/Be-Your-Own-Cert ... -Authority
https://legacy.thomas-leister.de/eine-e ... usstellen/

Nur ist mir nicht klar, wo ich am besten Key (.key) und Zertifikat (.crt) sowohl von der CA als auch für exim und dovecot im Filesystem ablege.
Ist es sinnvoll, für exim und dovecot (und auch apache) jeweils ein eigenes Zertifikat auszustellen, oder soll es eines für alle Dienste sein?

Ich installiere dann auf allen Endgeräten das CA.crt, damit ein allfällig aktualisiertes Zertifikat für exim, dovecot oder apache gegen dieses geprüft werden kann.
Dieses Zertifikat der CA kann ich ja prinzipiell öffentlich zugänglich machen? Mit dem kann man ja ansich eh nix anstellen. Der key der CA ist der Schlüssel für Bösartigkeiten (oder eben die Sicherheit der Verbindung).
Sehe ich das so richtig?

lg scientific
Zuletzt geändert von scientific am 01.08.2017 15:11:10, insgesamt 1-mal geändert.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

jeff84
Beiträge: 324
Registriert: 15.07.2009 13:32:36

Re: Eigene CA, Zertifikate, Pfade

Beitrag von jeff84 » 01.08.2017 13:44:27

scientific hat geschrieben: ↑ zum Beitrag ↑
01.08.2017 11:19:29
Nur ist mir nicht klar, wo ich am besten Key (.key) und Zertifikat (.crt) sowohl von der CA als auch für exim und dovecot im Filesystem ablege.
Ist es sinnvoll, für exim und dovecot (und auch apache) jeweils ein eigenes Zertifikat auszustellen, oder soll es eines für alle Dienste sein?

Ich installiere dann auf allen Endgeräten das CA.crt, damit ein allfällig aktualisiertes Zertifikat für exim, dovecot oder apache gegen dieses geprüft werden kann.
Dieses Zertifikat der CA kann ich ja prinzipiell öffentlich zugänglich machen? Mit dem kann man ja ansich eh nix anstellen. Der key der CA ist der Schlüssel für Bösartigkeiten (oder eben die Sicherheit der Verbindung).
Sehe ich das so richtig?

lg scientific
Den Key legt man am besten so ab, dass möglichst nur root Lesezugriff hat. Wo geau du das machen magst, ist erst mal egal. /etc/ bietet sich an. Oder du legst den Key der CA in einen encrypteten Container und mountest diesen nur, wenn du ein neues Zert unterschreiben willst.
Ich persönlich würde je Dienst ein eigenes Zertifikat, mit eigenem Key, ausstellen.

Das CA.crt ist nichts, was niemand anderes sehen darf. Also kannst du den theoretisch auch zum Download auf deine Homepage, Mega oder Dropbox legen. Nur auf den Key solltest du aufpassen.

wolfn
Beiträge: 30
Registriert: 03.07.2017 17:49:46

Re: Eigene CA, Zertifikate, Pfade

Beitrag von wolfn » 01.08.2017 22:19:50

Schau mal hier: https://jamielinux.com/docs/openssl-cer ... index.html
Danach habe ich meine CA aufgebaut. Die Anleitung ist nach meiner Meinung die beste im Netz.

Benutzeravatar
MF
Beiträge: 115
Registriert: 14.08.2003 12:04:05

Re: Eigene CA, Zertifikate, Pfade

Beitrag von MF » 03.08.2017 10:22:13

Ich würde mir den Aufwand mit eigener CA sparen und https://letsencrypt.org/ benutzen.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Eigene CA, Zertifikate, Pfade

Beitrag von scientific » 07.08.2017 09:57:20

An letsencrypt hab ich auch schon gedacht. Das mach ich ev. später einmal.
Mir gehts nicht nur um die Absicherung meiner Verbindung, mir geht es auch um den Lerneffekt.

Vielen Dank für die weiterführenden Links!
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Eigene CA, Zertifikate, Pfade

Beitrag von scientific » 10.08.2017 10:23:48

Ich steh grad an. Hab aber auch nicht wirklich Zeit mich gut damit zu beschäftigen.

Letsencrypt funktioniert aber mit localhost (nicht von außen erreichbar, bzw. nur per Portweiterleitung mit ssh) offenbar nicht. Dann doch eine eigene CA?
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

wolfn
Beiträge: 30
Registriert: 03.07.2017 17:49:46

Re: Eigene CA, Zertifikate, Pfade

Beitrag von wolfn » 10.08.2017 11:50:14

Also an letsencrypt führt wahrscheinlich kein Weg vorbei, wenn die Sache öffentlich von außen erreichbar sein soll, denn sonst blockieren alle 'fremden' Browser etc.

Weil ich das ganze aber nur privat für mich und max. Familie nutze, ist die eigene CA sicher besser, weil man da nicht alle Jahre das Zertifikat erneuern muß und alles selber in der Hand hat. Der Eintrag im Browser und was sonst noch zum Einsatz kommt ist schnell erledigt und man kann auch das Zertikat >1 Jahr laufen lassen.
Wenn man irgendwas 'versaut', kann man es dennoch jederzeit erneuern.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Eigene CA, Zertifikate, Pfade

Beitrag von scientific » 21.08.2017 15:58:32

Arbeite mich durch die Anleitung vom jamielinux (obiger Link) durch.

Aber verwirrend ist der Scheiß schon...

Habe mir von der CA über die intermediate-Geschichte erstmal ein Zertifikat für localhost ausgestellt, damit ich das mal am Rechner selber testen kann.

Für exim und dovecot muss ich demnach ein Server-Cert erzeugen. Dieses und den Key füttere ich dann der Konfiguration der beiden Server.
Und das intermediate Zertifikat muss ich dann auch den beiden Diensten bekannt geben?

Oder muss ich das ca-cert dem Rechner als CA hinterlegen? So wie ich das cert der CA auf jedem Rechner der auf den Mailserver zugriff hat, geben muss. Oder doch das intermediate.cert?

Öffne ich mit firefox so ein crt.pem, zeigt der den Text.
Lösche ich das .pem im Dateinamen, kann ichs importieren...

Darf man die so umbenennen?

Noch eine Verständnisfrage:
Ein ca-Zertifikat, oder ein Intermediate-Zertifikat hab ich auf meinem Clientrechner oder im Client installiert. Normalerweise sind das jene, die von einer offiziellen CA kommen und mit OS oder Browser (Mozilla) mutgeliefert werde.

Beim Aufbau einer TLS-Verbindung schickt der z. B. Mailserver ein Server-Zertifikat. Kann der Client das mit einem vorinstallierten CA-Cert verifizieren, wird die Verbindung sofort hergestellt.
Kanns der Client nicht verifizieren, kommt die Frage, ob ich dem Zertifikat vertraue oder nicht.

Stimmt das so?

Das Server-Zertifikat muss mit der Domain übereinstimmen... Daher brauch ich z. B. für exim ein Zert für localhost, eines für aldebaran.local (Zugriff übers LAN per zeroconf-hostname), eines für die IP im LAN, und eines für z. B. aldebaran.meinedomain.example,wenn ich den Mailserver auch von außen erreichbar mache.

Oder kann ich diese Domains alle in ein einziges Zertifikat packen?

In exim-gencert hab ich, glaub ich, so eine Lösung für ein Zertifikat für alle fqdns gesehen... Kann das sein?

Dann erzeuge ich am besten ein Zert mit allen Domains für exim, eins für dovecot, eins für den Webserver (Roundcube soll als Minimum da laufen)?
Oder hab ich da einen Knopf im Hirn?

Letsencrypt ist so eine Sache mit localhost...

Derzeit verbinde ich mich von außen per ssh und Portweiterleitung zu meinem Mailserver. Die domain ist dabei localhost, und letsencrypt (oder ich) steigt da aus.

Ich hab eine eigene Domain auch, wovon ich eine Subdomain auf diesen Rechner gesetzt habe. Das heißt, ich kann für die Subdomain für den Zugriff von außen sehr wohl ein letsencrypt-Zertifikat installieren.

Oder... Ginge das auch, dass ich mein ca-cert mit letsencrypg zertifiziere, und so meine Zertifizierungskette sowohl mit Fremdbrowsern von außen klappt, als auch mit der domain localhost und aldebaran.local?

So verwirrend das ganze. Und noch die zusätzliche Verwirrung mit den Dateinamenerweiterungen und Formaten der Keys und Certs und csr und crl...

Sorry für meine Aufdringlichkeit.
Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

wolfn
Beiträge: 30
Registriert: 03.07.2017 17:49:46

Re: Eigene CA, Zertifikate, Pfade

Beitrag von wolfn » 21.08.2017 23:36:01

Nur schonmal auf die Schnelle (war schon beim Abschalten):
Die Übung mit localhost ist nach meiner Meinung irreführend und nicht praxisrelevant.
Machst Dir nur extra Stress.

Die wichtigste Veranstaltung betrifft Webseiten und Browser!
Im Apache oder nginx mußt Du wie dort beschrieben Dein erstelltes Zertifikat hinterlegen (und den Key) und im Browser die öffentlichen Zertifikate (Verkettung aus CA-Top+Intermediate, Reihenfolge beachten!). Das geht über die Import-Seite im Browser (unter Extras/Zertifikate), habs aber erst im Firefox gemacht. Sollte mit den pem's aber gehen!
(-> Du mußt dem Browser die neue Zertifizierungsstelle, nämlich Deine CA, klarmachen.)
Ist jetzt alles aus dem Gedächtnis geschrieben, damit Du weiterkommst.

Dovecot kann selber certs erzeugen, habe ich auch schon benutzt und geht.
Ob Du die CA dafür auch einspannen kannst, kann ich im Moment nicht beantworten, ist auch noch ne Baustelle hier...
Bin morgen unterwegs, kann erst die Tage wieder antworten - viel Erfolg!

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Eigene CA, Zertifikate, Pfade

Beitrag von scientific » 22.08.2017 10:52:16

Ob localhost oder LAN oder öffentlich erreichbar... ich "übe" auf localhost, dann im LAN, und wenn es hier mit der eigenen CA funktioniert, schalte ich die Ports nach draußen frei...

Für mich relevant ist der Webbrowser nicht (wirklich). Ich möchte meinen Mailserver absichern. Und dazu muss es mit exim4 und dovecot klappen. Der Webserver wird niemals nach "draußen" gelegt. Webmail ist für mich nur relevant, wenn ich irgendwo eine ssh-Verbindung aufbauen kann und dann Forwarte ich die http/https-Ports über die gesicherte ssh-Verbindung.

So unterschiedlich können Anforderungen und Prioritäten sein :)

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

wolfn
Beiträge: 30
Registriert: 03.07.2017 17:49:46

Re: Eigene CA, Zertifikate, Pfade

Beitrag von wolfn » 23.08.2017 21:40:11

Habe mir jetzt nochmal den Artikel von Jamie hergeholt und nachgesehen:
scientific hat geschrieben: ↑ zum Beitrag ↑
21.08.2017 15:58:32
Für exim und dovecot muss ich demnach ein Server-Cert erzeugen. Dieses und den Key füttere ich dann der Konfiguration der beiden Server.
Und das intermediate Zertifikat muss ich dann auch den beiden Diensten bekannt geben?

Oder muss ich das ca-cert dem Rechner als CA hinterlegen? So wie ich das cert der CA auf jedem Rechner der auf den Mailserver zugriff hat, geben muss. Oder doch das intermediate.cert?
Du kannst für jeden (virtuellen) Server ein eigenes Zertifikat erzeugen, also z.B. mail.meinedom.com, es soll aber auch gehen *.meinedom.com.
Letzteres habe ich aber nicht hinbekommen, wohl irgendwas falsch gemacht oder nicht richtig gelesen.
Leztlich dürfte es wahrscheinlich sogar besser sein, lauter einzelne zu erzeugen, dann ist bei irgendwelchem Murks nur ein Server betroffen.

Diese Zertifikate müssen dann noch mit den private Keys der CA und -wenn eingerichtet- der Intermediate Authority 'beglaubigt' werden.

Dieser Prozeß ist in dem Material eigentlich sehr detailliert beschrieben, aber war für mich auch erst nach mehrmaligem Lesen und Probieren halbwegs klar...

Die .pem's , die da rauskommen, können unter /etc/ssl/certs abgelegt werden oder symlink oder auch da bleiben wo sie sind.
Die Zugriffsrechte sollten schon so sein, wie in dem Material beschrieben.

In der config des apache/nginx/*server gibt es dann einen (oder mehrere) Verweis(e) auf diese(s) .pem.

Nur die private Keys der CA und Intermediate sind absolut heiß und kostbar und sollten am besten ganz vom Rechner - Crypto-Stick oder so.
Mindestens der von der CA selber!

scientific hat geschrieben: ↑ zum Beitrag ↑
21.08.2017 15:58:32
Öffne ich mit firefox so ein crt.pem, zeigt der den Text.
Lösche ich das .pem im Dateinamen, kann ichs importieren...

Darf man die so umbenennen?
Wenn Du im Firefox zu 'Einstellungen-Erweitert-Zertifikate-Zertifikate anzeigen' gehst, wählst Du aus 'Zertifizierungsstellen' - dort findest Du einen Schalter für Importieren.
Hier gibst Du dem Firefox den ÖFFNTLICHEN Key Deiner CA (+ Intermediate) bekannt - Deine CA ist eine Zertifizierungsstelle!
Ich hatte keine Probleme, dort ein .pem reinzuladen.
Danach findest Du Deine 'Zertifizierunsstelle(n)' in bester Gesellschaft in der Liste.
Das sollte bei Chrome auch so gehen, ich hatte damit aber Probleme und habs erstmal links liegen lassen.

scientific hat geschrieben: ↑ zum Beitrag ↑
21.08.2017 15:58:32
Oder... Ginge das auch, dass ich mein ca-cert mit letsencrypg zertifiziere, und so meine Zertifizierungskette sowohl mit Fremdbrowsern von außen klappt, als auch mit der domain localhost und aldebaran.local?
Ich kann mir ehrlich gesagt nicht vorstellen, daß man bei LetsEncrypt jede -pardon- dahergelaufene CA zertifizieren würde, da könnte ja jeder kommen...
Aber möglicherweise machen die sowas gegen Geld und entsprechende Legitimation. Ob der Aufwand für privaten Einsatz noch im Verhältnis steht, mußt Du dann entscheiden.

scientific hat geschrieben: ↑ zum Beitrag ↑
21.08.2017 15:58:32
Noch eine Verständnisfrage:
Ein ca-Zertifikat, oder ein Intermediate-Zertifikat hab ich auf meinem Clientrechner oder im Client installiert. Normalerweise sind das jene, die von einer offiziellen CA kommen und mit OS oder Browser (Mozilla) mutgeliefert werde.

Beim Aufbau einer TLS-Verbindung schickt der z. B. Mailserver ein Server-Zertifikat. Kann der Client das mit einem vorinstallierten CA-Cert verifizieren, wird die Verbindung sofort hergestellt.
Kanns der Client nicht verifizieren, kommt die Frage, ob ich dem Zertifikat vertraue oder nicht.

Stimmt das so?
Na, nicht so ganz: Wie schon oben geschrieben - die Zertifikate sind auf dem Server und von der CA signiert. Und kommen immer mit zum Client.
Die Clients (sollten) haben die 'public keys' der CA(s), damit können sie sozusagen die 'Unterschriften' der Zertifikate prüfen.
Wenn nicht, fragt der Client, ob das so OK ist. Chrome und Firefox schmeißen neuerdings gleich alles hin.

scientific hat geschrieben: ↑ zum Beitrag ↑
21.08.2017 15:58:32
Das Server-Zertifikat muss mit der Domain übereinstimmen... Daher brauch ich z. B. für exim ein Zert für localhost, eines für aldebaran.local (Zugriff übers LAN per zeroconf-hostname), eines für die IP im LAN, und eines für z. B. aldebaran.meinedomain.example,wenn ich den Mailserver auch von außen erreichbar mache.

Oder kann ich diese Domains alle in ein einziges Zertifikat packen?
Im Prinzip kannst Du - siehe oben - aber es hat auch ein paar Einschränkungen, die sind in dem Material auch beschrieben.
Ich habe mich erstmal entschieden, lauter einzelne zu nehmen.

Zu der Geschichte mit .local noch eine Warnung: Im Zusammenhang mit meinem unbound und DNS bin ich über einen Hinweis gestolpert, daß dieser Suffix für bestimmte Hardware festverdrahtet ist und Du im Pech-Fall üble Kollisionen produzierst.
Habs gerade nicht griffbereit, aber Tante Google weiß bescheid...

So, jetzt geht mir langsam die Puste aus. Wenn ich was übersehen/vergessen habe, frag einfach nochmal nach.
Aber auf alles habe ich auch nicht immer eine Antwort ;-)

Schöne Grüße und fröhliches Basteln...

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Eigene CA, Zertifikate, Pfade

Beitrag von scientific » 24.08.2017 08:36:58

Vielen Dank für deine Erläuterungen.

Ich habs in der Zwischenzeit schon zum laufen bekommen.

Die ca-chain.cert.pem hab ich in ca-chain.crt umbenennen müssen und auf meinem Smartphone per FTP abgelegt. Dann kann ich es über den Dateimanager mit antippen öffnen und als Eigene CA installieren. *.pem verweigert Android 7.

Ich konnte mit DNS.1=localhost, DNS.2=aldebaran.local und DNS.3=aldebaran.meinedomain.example alle 3 Domains in das Zertifikat für exim und das für dovecot aufnehmen.
Die ca-chain.cert.pem konnte ich sowohl in Thunderbird als CA hinterlegen und in /etc/ssl/certs ablegen und mit update-ca-certificates im System "registrieren".

Apache habe ich mit dem cert.pem und dem key.pem konfiguriert.

In Chromium, Firefox und Thunderbird habe ich ebenfalls die Datei ca-chain.cert.pem importiert. Alle Verbindungen werden nun als sicher angezeigt bzw. ohne Nachfrage wegen des Zertifikates geöffnet.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Eigene CA, Zertifikate, Pfade

Beitrag von scientific » 28.08.2017 16:26:34

Ich bin begeistert.
Das ca-chain.cert.pem auf den diversen Clients (Linux, Android, Windows) als CA importiert erlaubt sowohl im Browser als auch den Mailclients ssl-geschützte verbindungen ohne eine Ausnahme erlauben zu müssen.

Die Server-Zertifikate hab ich sowohl mit localhost, dem zeroconf-Hostname als auch der von außen erreichbaren Domain ausgestattet.
Daher reich ein Zertifikat für alle möglichen Zugriffe.

Hab mir aus den Befehlen in der Anleitung 3 Skripte gebaut, die Configs auf meine Bedürfnisse angepasst und kann so die CA, das intermediate-chain-cert und die Certs für Apache, dovecot und exim getrennt erstellen.

Jetzt kommt als nächster Schritt ein openVPN-Server dazu. Da ich jetzt halbwegs gecheckt habe, wie das mit den Zertifikaten funktioniert. :hail:
Und dann übersiedle ich das ganze in ein Selbstbau-NAS auf Einplatineng-Comp-Basis

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Eigene CA, Zertifikate, Pfade

Beitrag von scientific » 30.08.2017 17:17:41

Jetzt hab ich nur noch ein "Problem".

Wie ich das intermediate-Zertifikat per deb verteile, weiß ich.
Wie mach ichs aber per deb für Mozilla? Und Chrome?
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Eigene CA, Zertifikate, Pfade

Beitrag von scientific » 02.09.2017 18:21:28

Also auch dafür konnte ich eine Lösung finden.

Ich verteil das CA-Zertifikat "einfach" mit einem Paket, indem ich es in /etc/ssl/certs ablege.

Zusätzlich habe ich mir ein Skript gebaut, welches alle User mit Homeverzeichnis sucht, die eine UID haben, die in den Grenzen von adduser FIRST_UID und LAST_UID liegt.
Und diesen User trage ich das CA-Cert in die Datenbank mit certutil ein.
Dieses Skript liegt in /etc/ca-certificates/update.d/ und wird mit jedem Update der Zertifikate mit geupdated

Code: Alles auswählen

update-ca-certificates
Das Paket ist noch nicht ganz fertig, und das Skript hat noch die FIRST_UID und LAST_UID manuell eingetragen, und die Prüfung auf ein vorhandenes HOME ist auch noch nicht drin.
Weiters fehlt noch das Entfernen des Zertifikates bei Deinstallation des Pakts.

Aber es funktioniert bereits. Ich hab schon probehalber auf einem Rechner die CA per Paket installiert und dann jungfräulich mit Thunderbird Mails abgerufen und versendet. Und den Webserver konnte ich auch schon erfolgreich mit https:// erreichen ohne nachfrage, ob eine Ausnahme hinzugefügt werden soll.

So soll das sein.

Wenn das Paket/Skript fertig ist, stell ich's gern hier zur Verfügung.

lg scientific

PS: Ich weiß jetzt schön langsam, warum der Debian-Way oft so anders und manchmal kompliziert ist/erscheint... damit lassen sich nämlich wirklich viele Dinge per DEB-Installation automatisieren, für die man bei anderen Distris bloß Würgarounds und manuell hingestricktes findet... (im Netz in den Foren).

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Antworten