In Zeiten der Vollüberwachung durch die NSA und andere Geheimdienste weltweit sind auch die bekannten Certificate Authorities (CA) wie z.B. Verisign nicht mehr wirklich vertrauenswürdig. Man kann davon ausgehen, dass die NSA auch Zugriff auf die Schlüssel dieser CAs hat, sodass sie gefälschte Zertifikate ausstellen kann. Diese können dann dazu dienen, Datenverkehr zu manipulieren und mitzuschneiden. So ist die Verschlüsselung natürlich nutzlos und private Daten gelangen in falsche Hände.
Wer sich unabhängig von den großen, offiziellen Certificate Authorities machen will, kann ganz einfach seine eigene eröffnen. Dazu braucht es nicht mehr als eine Ubuntu / Linux – Installation und das OpenSSL Paket, das alles mitbringt, was wir für das Erzeugen der Zertifizierungsstelle und das Signieren von Serverzertifikaten brauchen. Diese selbst erstellten Zertifizierungsstellen und die von ihnen signierten Zertifikate sind natürlich nicht von Browsern und Betriebssystemen anerkannt, sodass diese Warnmeldungen ausgeben. Das kann man aber verhindern, indem man auf diesen Computern das CA Root Zertifikat installiert.
Anmerkung zu diesem Beitrag:
Diese Anleitung ist bereits etwas älter. Ich habe eine einfachere, schnellere Möglichkeit gefunden, eine CA zu verwirklichen, mit der sich eigene Zertifikate ausstellen lassen. Bitte folgt diesem Link, um zu meiner aktualisierten Anleitung zu gelangen:
https://legacy.thomas-leister.de/eine-eigene-openssl-ca-erstellen-und-zertifikate-ausstellen/
Es folgt die veraltete Anleitung.
Stellt zuerst sicher, dass OpenSSL installiert ist:
sudo apt-get install openssl
Ihr solltet euch gerade im Homeverzeichnis befinden. Dort erstellen wir jetzt einen Ordner für unsere Zertifizierungsstelle, in dem sich später alle benötigten Dateien befinden werden.
mkdir ca cd ca mkdir certs newcerts private
In diesem CA Ordner werden außerdem drei weitere Ordner erstellt. „certs“ und „private“ enthalten später das Root-Zertifikat der Certificate Authority und „private“ die streng geheime private Schlüsseldatei. Diese wird besonders gut geschützt:
chmod 700 private
Damit das Script zur Generierung der Certificate Authority funktioniert, werden außerdem noch zwei Dateien benötigt, die so erzeugt werden:
echo '01' > serial touch database.txt
Die Dateistruktur im Homeverzeichnis sollte jetzt so aussehen:
- Home
- ca
- certs
- newcerts
- private
- serial
- database.txt
- ca
CA Konfiguration erstellen
Als nächstes muss die Konfigurationsdatei „caconfig.cnf“ erstellt werden, in die die Einstellungen für die Zertifizierungsstelle geschrieben werden:
nano caconfig.cnf
Inhalt der Datei:
[ ca ] default_ca = CA_default [ CA_default ] dir = ./ certs = $dir/certs crl_dir = $dir/crl database = $dir/database.txt new_certs_dir = $dir/newcerts certificate = $dir/certs/cacert.pem serial = $dir/serial private_key = $dir/private/cakey.pem x509_extensions = usr_cert default_days = 3650 default_md = sha1 preserve = no policy = policy_match [ policy_match ] countryName = match stateOrProvinceName = match localityName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] default_bits = 4096 default_keyfile = cakey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca string_mask = utf8only req_extensions = v3_req [ req_attributes ] [ req_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = DE countryName_min = 2 countryName_max = 2 stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Germany localityName = Locality Name (city, district) organizationName = Organization Name (company) organizationalUnitName = Organizational Unit Name (department, division) commonName = Common Name (hostname, FQDN, IP, or your name) commonName_max = 64 emailAddress = Email Address emailAddress_max = 40 [ usr_cert ] basicConstraints= CA:FALSE subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always nsComment = ''OpenSSL Generated Certificate'' subjectAltName=email:copy issuerAltName=issuer:copy [ v3_req ] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment [ v3_ca ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always basicConstraints = CA:TRUE
Die Konfiguration könnt ihr so 1:1 übernehmen.
Certificate Authority generieren
… die Generierung der CA beginnt mit der Erzeugung eines Private Keys, der unter private/cakey.pem gespeichert wird.
openssl req -new -x509 -days 3650 -config caconfig.cnf -keyform PEM -keyout private/cakey.pem -outform PEM -out certs/cacert.pem
Dieser Befehl erzeugt Zertifikate mit einer Gültigkeitsdauer von 10 Jahren. Das sollte erst einmal reichen ;)
Ihr werdet nach verschiedenen Daten gefragt. Zuerst müsst ihr eine PEM Passphrase vergeben, mit der die Cert. Auth. vor unbefugten Zugriffen geschützt wird. Dieses Passwort sollte möglichst lang und komplex sein.
Danach werdet ihr nach verschiedenen Attributen gefragt, die die CA haben soll. Dazu gehören Länderkürzel, Land, Stadt, Firmen- oder Organisationsname, Name des Erstellers der Zertifizierungsstelle und E-Mail Adresse. Ihr könnt hier eintragen, was ihr wollt. Seid kreativ!
Das war’s auch schon. Die Certificate Authority ist jetzt erstellt und Root-Zertifikat und der dazugehörige Private Key liegen in den entsprechenden Ordnern, die wir vorher angelegt haben. Das öffentliche Root-Zertifikat liegt jetzt in „certs“ und der private Schlüssel in „private“. An dieser Stelle ist es sinnvoll, ein Backup von beiden Dateien zu machen. Gehen die Dateien verloren, kann man mit dieser CA keine Zertifikate mehr erstellen und muss eine neue CA aufbauen. Dabei müssen dann ggf. auch alle bisher ausgestellten Serverzertifikate erneuert werden. Also: Unbedingt den CA Ordner sichern!
Das öffentliche Zertifikat (certs/cacert.pem) muss später auf alle Rechner importiert werden, auf denen man später keine SSL Warnungen bekommen will. Wie zu Beginn schon erklärt, ist die selbst erstellte CA nämlich nicht von Betriebssystemen und Browsern anerkannt, sodass es zu Warnmeldungen kommt. Installiert man dagegen das Root-Zertifikat der CA, ist auch die selbst erstellte CA Browsern und Betriebssystem bekannt und wird akzeptiert.
Unser Root-Zertifikat liegt im .pem Format vor. Windows beispielsweise nimmt aber nur Zertifikate im DER Format an, sodass man das .pem Zertifikat konvertieren muss:
openssl x509 -in certs/cacert.pem -outform der -out certs/cacert.crt
Jetzt liegen Zertifikate beider Typen im Ordner „certs“ und können auf andere Computer übertragen werden, wo man sich dann importieren kann.
(CA Root Zertifikate können in Mozilla Firefox über „Einstellungen => Erweitert => Verschlüsselung => Zertifikate anzeigen => Zertifizierungsstellen => Importieren“ importiert werden.)
Serverzertifikate generieren
Die Zertifizierungsstelle ist jetzt fertig und einsatzbereit. Fehlen noch die Zertifikate, die dann von der Certificate Authority signiert werden können und schließlich zum Einsatz kommen. Mit diesen Zertifikaten kann dann beispielsweise ein Webserver abgesichert werden.
Für die Arbeit mit den Serverzertifikaten wird ein weiteres Verzeichnis „myssl“ neben dem „ca“ Verzeichnis erstellt:
mkdir myssl cd myssl
Innerhalb dieses myssl Ordners gibt es zwei Unterordner „private“ und „public“. Wie die Namen schon vermuten lassen, enthält der „private“ Ordner den privaten, geheimen Schlüssel, der später zum öffentlichen Zertifikat passt, welches sich in „public“ befinden wird. Dieser private Schlüssel, von dem die Rede ist, ist übrigens ein ganz anderer, als der der Zertifizierungsstelle. CA und Serverzertifikate müssen streng getrennt betrachtet werden. Wir sind hier gerade mit den Serverzertifikaten beschäftigt.
Erstellen wir also die eben angesprochenen Unterordner:
mkdir private public
Wie bei der Generierung der CA muss auch hier ein zufälliger Private Key erzeugt werden:
openssl genrsa -out private/privkey.pem 4096
… der ebenfalls gut geschützt wird:
chmod -R 700 private/privkey.pem
Im nächsten Schritt wird eine Zertifikatsanfrage gestellt, welche dann von der CA verarbeitet werden wird:
openssl req -new -key private/privkey.pem -out cert-req.pem
Wieder werden einige Attribute zum Zertifikat abgefragt. Mit einem Unterschied: Das Feld „Common Name / FQDN“ muss den Domainnamen enthalten, für den das SSL Zertifikat gelten soll. Will ich also meine Domain meinedomain.tld absichern, muss das so eingegeben werden. Ohne Protokoll; einfach nur „meinedomain.tld“. Subdomains wie z.B. „rss.meinedomain.tld“ kann man mit einem Wildcard-Zertifikat absichern, das dann für alle Subdomains gilt (auch www.meinedomain.tld). Dazu schreibt man „*.meinedomain.tld“.
Schließlich erhält man die Zertifikatsanfrage „cert-req.pem“.
Um die Anfrage zu bearbeiten und das Zertifikat von der Certificate Authority signieren zu lassen, wechseln wir wieder in das CA Verzeichnis:
cd ../ca/
… und führen folgenden Befehl aus:
openssl x509 -days 3650 -CA certs/cacert.pem -CAkey private/cakey.pem -req -in ../myssl/cert-req.pem -outform PEM -out ../myssl/public/cert.pem -CAserial serial
Man wird nach der PEM Passphrase der Certificate Authority gefragt und muss den Vorgang zwei mal mit „y“ bestätigen. Damit wird das öffentliche Zertifikat für die angegebene Domain erzeugt und landet in myssl/public/cert.pem
Die Zertifikatsanfrage kann jetzt wieder gelöscht werden; sie wird nicht mehr benötigt:
cd ../myssl/ rm cert-req.pem
Nach jedem Unterzeichnungsvorgang kann dann das fertige, öffentliche Zertifikat (myssl/public/cert.pem) zusammen mit dem immer gleich bleibendem private Key (myssl/private/privkey.pem) exportiert werden und auf einem Webserver benutzt werden. Dazu auch: Webserver absichern mit SSL. (Artikel ab Aktivierung von mod_ssl) Danach kann man das öffentliche Zertifikat ebenfalls löschen.
rm public/cert.pem
Für alle weiteren Zertifikate, die erstellt werden sollen verfährt man genauso. Nur der Private Key muss nicht mehr erzeugt werden. Der Ablauf für jedes weitere Zertifikat ist also wie folgt:
- Zertifikatsanfrage stellen und Daten eingeben (Auf Domainnamen achten!)
- Zertifikatsanfrage von der Certificate Authority verarbeiten lassen
- cert.pem und eine Kopie von privkey.pem auf den Webserver kopieren, wo SSL genutzt werden soll
- Zertifikatsanfrage und öffentliches Zertifikat können wieder gelöscht werden.
Der Ordner für die Zertifizierungsstelle bleibt unverändert. Hier also bitte nichts löschen ;)
http://www.discover-kyrgyzstan.com
Hallo, das ist der Artikel, auf den ich gewartet habe….
Leider bleibe ich an einer Stelle stecken: Zur Nutzung des gerade erstellten Zertifikats verweist Du auf den ‚Webserver absichern mit SSL‘ . Dort wird aber mit Dateien ‚xx.key‘ und ‚xx.crt‘ hantiert, wie sie beim SelfCert ohne CA entstehen.
Was muss ich in der Konfiguration zu meinem Virtual Host eintragen, wenn ich die beiden .pem Dateien habe?
Merci, Wolfgang
https://legacy.thomas-leister.de
Hi Wolfgang!
Der Apache Webserver frisst auch .pem, also einfach statt .crt und .key die beiden .pem Dateien einbauen, das sollte funktionieren :)
LG Thomas
Hi,
scheitere leider beim generieren der Certificate Authority, nachdem ich die pass phrase zwei mal eingegeben habe kommt der Fehler:
unable to find 'distinguished_name' in config
problems making Certificate Request
140426476439232:error:0E06D06C:configuration file routines:NCONF_get_string:no value:conf_lib.c:335:group=req name=distinguished_name
Benutze Ubuntu 13.04 und bin als root angemeldet.
Vielen dank schon mal!
https://legacy.thomas-leister.de
Auf dieser Seite findet man folgendes: http://www.openssl.org/support/faq.html
4. Why can’t I create certificate requests?
You typically get the error:
unable to find ‚distinguished_name‘ in config problems making Certificate Request
This is because it can’t find the configuration file.
Sieht also so aus, als könnte die Konfigurationsdatei nicht gefunden werden. Vllt beim Dateinamen vertippt?
LG Thomas
http://luisgerhorst.de
Das gleiche hab ich auch gefunden aber der Dateiname war eigentlich richtig. Ich probiers heute nochmal, vllt. klappts ja diesmal.
Hi Thomas,
genau was ich gesucht habe.
Vielen Dank für Deinen Beitrag und Deine Mühen.
Mein Server läuft jetzt mit eigenem Zertifikat. :-)
Gruß
Uwe
Mit den Rechten 600 für das private-Verzeichnis kommt es zu diesem Fehler:
openssl req -new -x509 -days 3650 -config caconfig.cnf -keyform PEM -keyout private/cakey.pem -outform PEM -out certs/cacert.pem
Generating a 4096 bit RSA private key
…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………..++
………………………….++
writing new private key to ‚private/cakey.pem‘
private/cakey.pem: Permission denied
5141:error:0200100D:system library:fopen:Permission denied:bss_file.c:356:fopen(‚private/cakey.pem‘,’w‘)
5141:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:358:
Nach „chmod 700 private“ funktioniert es.
Dafür reicht für die cakey.pem auch ein 400
Hi,
der Befehl
echo '01' > serial
spuckt bei mir die folgende Meldung aus:
-bash: serial: Keine Berechtigung
Gibt es einen Tip für mich?
LG Chris
https://legacy.thomas-leister.de
Anscheinend hast du nicht genügend Rechte auf dem System. Versuche es mal, indem du via
sudo -s
Adminrechte übernimmst.LG Thomas
Großartiges Tutorial. Thanks for sharing!! :)
Was noch fehlt ist die Erzeugung einer p12-Datei für den Import in den Windows Zertifikatsspeicher, etwa:
openssl pkcs12 -export -in servercert.pem -inkey serverkey.pem -certfile cacert.pem -name „p12-cert“ -out cacert.p12
Wenn ich dem Tutorial folge, welche Dateien sind mit servercert.pem und serverkey.pem gemeint?
Die in myssl/public/ oder ?
https://legacy.thomas-leister.de
Der serverkey wäre privkey.pem und servercert wäre public.pem ;)
LG Thomas
Und wie wird ein entsprechendes Zertifikat mit openssl chiper ecdhe-rsa-aes256-gcm-sha384 erzeugt?
Ansonsten super Tutorial
https://legacy.thomas-leister.de
Sorry, da bin ich überfragt.
LG Thomas
Das ist egal, jedes Zertifikat ist mit jedem cipher kompatibel.
Guter Beitrag,
kleiner Hinweis noch bei der Rechtevergabe. Für das Verzeichnis „ca/private“ wird 600 gesetzt die darin enthaltene Datei übernimmt die Rechte aber nicht rekursiv bzw. vererbt. Besser nach Generierung der keys die „private“-Key Verzeichnisse mit
chmod -R 600 private
anpassen.
https://legacy.thomas-leister.de
Thx für den Hinweis! Ist verbessert.
LG Thomas
Hallo Thomas,
schönes Tutorial, vielleicht noch ein kleiner Zusatz:
Wer sicher gehen will, dass die Verbindung zwischen Client (Browser) und Webserver AES 256 Bit verschlüsselt ist, der muss zwei Zeilen in der Webserver config hinzufügen.
Unter httpd.conf (bei Plesk Installationen und vhosts zusätzlich zur httpd.conf eine vhost_ssl.conf Datei erstellen, im Unix Format und ANSI Kodierung, da Plesk bei jeder Änderung eine neue xxxxx_http.conf erstellt).
Wer noch SSLv3 Unterstützung verwenden möchte kann hinter SSLProtocol -ALL auch noch +SSLv3 setzen.
SSLCipherSuite AES256-SHA
SSLProtocol -ALL +TLSv1
Natürlich noch ggf. die neue config aktivieren mit /usr/local/psa/admin/bin/httpdmng –reconfigure-all
Anschließend Webserver neustarten.
Coole Anleitung.
Bleibt für mich nur die Frage wie bitte dem Seitenbesucher auf Vertrauenswürdigem Weg das Root Zertifikat übergeben werden soll.
Für den Gebrauch in den eigenen vier Wänden mag das ja funktionieren, aber sobaldman das auch für andere Seitenbesucher alsnur man selbst braucht fällt mir keine wirklich praktikable Möglichkeit ein zu gewährleisten, dass kein „man in the middle“ Angriff möglich ist.
https://legacy.thomas-leister.de
Ja, das ist tatsächlich ein Problem. Vielleicht wäre eine Lösung, das Zertifikat inkl. Footprint) über einen Service zu übermitteln, der mit einem anerkannten Zertifikat arbeitet.
LG Thomas
Hallo Thomas,
wenn ich richtig verstanden habe, müsste ich dann für den Server aus dem privkey.pem folgendes erstellen:
openssl req -new -key privkey.pem -out server.csr
openssl x509 -req -days 3650 -in server.csr -signkey privkey.pem -out server.crt
oder erstelle ich es aus public/cert.pem?
Ok ich glaub, ich kapiere das jetzt
In der anderen Einleitung heißen die Dateien:
server.crt server.csr server.key
Das entspricht den Namen in dieser Einleitung:
server.crt = public/cert.pem
server.key = private/privkey.pem
Und die Datei server.csr muss durch den Befehl angelegt werden:
openssl req -new -key private/privkey.pem -out server.csr
Und das wars auch schon, oder?
Leider funktioniert das nicht.
Mein Browser sagt: „Es kann keine sichere Verbindung zum Server hergestellt werden. Möglicherweise liegt ein Problem mit dem Server vor oder es ist ein Client-Authentifizierungszertifikat erforderlich, das Sie nicht haben.“
Fehlercode: ERR_SSL_PROTOCOL_ERROR
Ich habe den Schlüssel allerdings bei mir auf dem Mac erfolgreich importiert.
Laut /var/log/apache2/error.log:
[warn] RSA server certificate wildcard CommonName (CN) `*.blubladomain.de‘ does NOT match server name!?
[warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
Was ist falsch?
https://legacy.thomas-leister.de
Der Apache Log sagt es eigentlich schon. ;) es wird ein Zertifikat genutzt, das für Subdomains von blubladomain.de gültig ist, aber nicht für andere Domains oder die blubladomain.de-Domain an sich. Bist du sicher, dass du eine Subdomain bzw www. vor blubladomain.de stehen hast, wenn du die Seite via Browser aufrufst?
LG Thomas
Hi Thomas,
ich habe zwei Subdomains (zwei Vhosts) angelegt. Daher habe ich ja Wildcard-Zertifikat für *.blubladomain.de erstellt, damit alle Subdomains über das gleiche Zertifikat verschlüsselt werden. Im Moment versuche ich die Verschlüsselung wenigstens für einen Vhost (seafile) zum Laufen zu bringen.
Vielleicht sind meine Vhosts falsch angelegt. Ich blick langsam nicht mehr durch bei allen Einleitungen die ich so gelesen habe, wie vhosts richtig anzulegen sind.
Hier meine Config. Hast Du evtl. einen Tipp woran es liegen könnte?
ServerName seafile.blubladomain.de
ServerAdmin webmaster@blubladomain.de
DocumentRoot /var/www/web0/html/seafile/
SuexecUserGroup web0 www-data
SSLEngine on
SSLCertificateKeyFile /pfad/mycert/privkey.pem
SSLCertificateFile /pfad/mycert/cert.pem
ServerSignature On
SSLProtocol All -SSLv2 -SSLv3
# SSLCompression off
SSLHonorCipherOrder On
SSLCipherSuite EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
Header add Strict-Transport-Security „max-age=15768000“
FCGIWrapper /var/www/web0/html/seafile/conf_seafile .php
SetHandler fcgid-script
Options +ExecCGI
Order allow,deny
allow from all
ErrorLog /etc/apache2/seafile_log/error.log
LogLevel warn
CustomLog /etc/apache2/seafile_log/access.log combined
Alias /media /var/www/web0/html/seafile/seafile-server-latest/seahub/media
RewriteEngine On
Require all granted
#
# seafile httpserver
#
ProxyPass /seafhttp http://127.0.0.1:8082
ProxyPassReverse /seafhttp http://127.0.0.1:8082
RewriteRule ^/seafhttp – [QSA,L]
#
# seahub
#
RewriteRule ^/(media.*)$ /$1 [QSA,L,PT]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /fcgi/seahub.fcgi$1 [QSA,L,E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
da fehlen doch Anfang- und End-Tags: VirtualHost *:443 …
https://legacy.thomas-leister.de
Die Tags werden rausgefiltert vom Kommentarsystem wegen HTML… aber pack die Config nächstes mal in code tags, dann bleiben sie erhalten.
Eigentlich sollte die Config okay sein… kann auch keinen Fehler finden. :-/
Super Anleitung. Kleine Ergänzung: für erhöhte Sicherheit sollte beim Signieren besser SHA256 statt SHA1 verwendet werden (Paramter -sha256).
Hi Thomas,
auch meinerseits vielen Dank für dieses ausführliche Tutorial! Eine Frage noch: wofür ist der Ordner „newcerts“? Er wird in deinem Tut scheinbar nicht verwendet.
Auch von mir ein großes Danke für die guten Erklärungen.
Aber auch ich habe noch ein kleines Problemchen: Zertifikate usw. alle nach Anleitung erstellt und das CA Zertifikat mit update-ca-certificates korrekt integriert. Allerdings schmeißt mein firefox noch die folgende Fehlermeldung bezüglich des Zertifikats:
The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer)
Was habe ich falsch gemacht oder vergessen?
(arch linux, openssl 1.0.1.h, firefox 30.0)
die Zeile cd ../ca/ ist nicht korrekt: cd ../ wäre richtig
lg Jürgen Bambusch
Die Zeile
„openssl x509 -days 3650 -CA certs/cacert.pem -CAkey private/cakey.pem -req -in ../myssl/cert-req.pem -outform PEM -out ../myssl/public/cert.pem -CAserial serial“
sollte richtig heißen
„openssl x509 -days 3650 -CA certs/cacert.pem -CAkey private/cakey.pem -req -in ./myssl/cert-req.pem -outform PEM -out ./myssl/public/cert.pem -CAserial serial“
— da sind ein paar Pkt zu viel :–) aber sonst eine sehr gute Anleitung
LG J. Bambusch
die Zeile
cd ../myssl sollte cd ./myssl sein
LG J. Bambusch
in der Zeile sind auch punkte zu viele drin:
openssl x509 -days 3650 -CA certs/cacert.pem -CAkey private/cakey.pem -req -in ../myssl/cert-req.pem -outform PEM -out ../myssl/public/cert.pem -CAserial serial
LG J. Bambusch
Hallo,
kann ich mit denen durch das Tutorial erstellten Zertifikaten alles absichern? bsp( iDrac, switches, firewall) und
So wie ich das verstanden habe laufen die Zertifikate ja alle durch das selbe Verzeichnis das man mit einem Pw schützen kann. Ich möchte eine einheitliche Struktur/ein Verzeichnis, das ich dem Browser hinzufügen kann und somit alle internen Zertifikate akzeptiert werden. Ist diese Anleitung dafür die Richtige?
Liebe grüße
Johanna
https://legacy.thomas-leister.de/ueber-mich-und-blog/
Ja, wenn du dir deine eigene CA baust und das Root-Zertifikat z.B in deinen Browser importierst … werden alle Zertifikate jeglicher Art, die durch diese CA ausgestellt wurden, akzeptiert. :)
LG Thomas
Vielen Dank :)
Das hilft mir sehr.
Liebe Grüße
Johanna