cosinus
Anmeldungsdatum: 11. Mai 2010
Beiträge: 1374
Wohnort: HB
|
misterunknown schrieb: cosinus schrieb: Nix Konkretes.
Das ist immer schlecht.
Bitte sachlich bleiben und keinen Stuss vorwerfen/unterstellen... Wenn ein Browser bei Zertifikaten vor Unsicherheit warnt hat das zu 99% einen der folgenden Gründe:
Der CA wird nicht generell nicht vertraut. Das ist bei selbstsignierten Zertifikaten der Fall für die weder die CA importiert wurde, noch eine Ausnahme definiert. Der aufgerufene Name steht nicht in den SubjectAlternativeNames. Das Zertifikat ist abgelaufen, also nicht mehr gültig.
Hab ich denn irgendwas Gegenteiliges behauptet? Nein, denn bei einer Warnung ist die Gegenseite eventuell kompromittiert. Das kann bei HTTP zwar auch passieren, allerdings macht man über HTTP auch keine wichtigen Sachen, wie Online-Banking oder Einkäufe. Daher warnen die Browser auch mittlerweile bei Passworteingaben über HTTP.
Hast du mal gelesen was ich geschrieben habe? Wenn ich etwas für ein breites Publikum anbiete, ja dann sollte ich auch zusehen, dass mit meinem Cert alles stimmt. Will ich aber nur (intern) schnell nen Server anbieten zB für eine Gruppe von Personen, die mich mich persönlich kennt und dir mir auch vertraut, dann ist ein selfsigned Cert nicht sicherer oder unsicherer als ein "offizielles" Cert. GGf teile ich denen noch den Fingerprint mit zum Abgleich wer will. Läuft doch bei SFTP/SSH oder Mailverschlüsselung mit gnupg auch nicht viel anders Da bin ich mir nicht sicher. Ich würde aber erwarten, dass die Ausnahme nur das Vertrauen garantiert. Wenn das Zertifikat beispielsweise abgelaufen ist, sollte man zumindest darauf hingewiesen werden.
Es kommt beim nächsten Besuch nicht schon wieder eine schrillende Warnung, dass der Rechner oder so in die Luft geht nur weil man eine HTTPS-Seite mit selfsigned Cert besucht 😊 Ein grünes Schloss mit gelbem Ausrufezeichen hab ich natürlich im FF in der Adressleiste. Nun, ich hau einfach eine dauerhafte Ausnahme rein wenn ich einen internen HTTPS besuche. Das musst du dann aber für jede Seite, die du intern besuchst einzeln machen. Wenn du einfach deine CA importierst, akzeptiert der Browser alle Zertifikate, die damit unterschrieben sind.
Ja, und? Das hab ich aber auch nur bei eigenen aufgesetzten (internen) Servern. Nur weil es selfsigned ist, heißt es ja nicht, dass es automatisch unsicher ist.
Doch. Wenn du bei dir intern irgendwelche eigenen Zertifikate nutzt, dann weißt du das natürlich, aber der Browser nicht. Ihm muss das also erst beigebracht werden. Bei anderen Seiten, beispielsweise Paypal oder Amazon oder so, sollte man sich unbedingt die Fehlermeldung genau angucken, weil das auf eine MITM-Attacke hindeutet.
Nein, nochmal, die Verschlüsselung ist nicht perse besser nur weil Symantec, Thawte, Letsencrypt oder der Papst persönlich mein Cert abgenickt hat. 😛 😊 Du hast aber Recht, wenn man ne offizielle Seite wie paypal, amazon oder seine Bank aufruft und dann eine Warnung bekommt, dann hat man wohl ne Fakeseite geöffnet oder was anderes stimmt nicht (zB MITM wie du ja auch erwähnt hast). Komischerweise kommt keine deutliche Warnung wenn man auf eine plainhttp-Seite geht - da gibt es nur bei den login-Feldern einen Hinweis im Firefox (seit v52 (?)) - Laien fühlen sich dadurch belästigt (!!) und wollen diese Warnung abschalten 😲 hab ich schon mehrmals gelesen 😕 edit: typo
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6473
|
cosinus schrieb: Komischerweise kommt keine deutliche Warnung wenn man auf eine plainhttp-Seite geht
siehe https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/
What to expect in the future
To continue to promote the use of HTTPS and properly convey the risks to users, Firefox will eventually display the struck-through lock icon for all pages that don’t use HTTPS, to make clear that they are not secure. > As our plans evolve, we will continue to post updates but our hope is that all developers are encouraged by these changes to take the necessary steps to protect users of the Web through HTTPS.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
cosinus schrieb: misterunknown schrieb: cosinus schrieb: Nix Konkretes.
Das ist immer schlecht.
Bitte sachlich bleiben und keinen Stuss vorwerfen/unterstellen...
Das war absolut nicht negativ oder so gemeint ☺ Es ist nur so, dass es eine überschaubare Anzahl von Eigenschaften im Zertifikat gibt, daher gibt es auch nur begrenzte Möglichkeiten für Fehler. Als ich mich mit Zertifikaten und PKI beschäftigt habe, war es mir immer eine Hilfe einfach mal so ein Ding herzunehmen und alle Eigenschaften anzeigen zu lassen, also beispielsweise:
openssl x509 -noout -text -in /pfad/zum/cert | less
Will ich aber nur (intern) schnell nen Server anbieten zB für eine Gruppe von Personen, die mich mich persönlich kennt und dir mir auch vertraut, dann ist ein selfsigned Cert nicht sicherer oder unsicherer als ein "offizielles" Cert. GGf teile ich denen noch den Fingerprint mit zum Abgleich wer will. Läuft doch bei SFTP/SSH oder Mailverschlüsselung mit gnupg auch nicht viel anders
Wie sagt, ich wollte dich gar nicht korrigieren, sondern ergänzen. Natürlich sind im privaten, internen Umfeld selbstsignierte Zertifikate kein Problem, gerade wenn alles unter deiner Hoheit steht. Dennoch kann es Sinn machen, nicht nur einzelne Zertifikate auszustellen, sondern eine "richtige" CA. Das hat den Vorteil, dass man viel lernt, und das CA-Zertifikat auch ggf. weitergeben kann. Dann muss man nicht so viele Ausnahmen verwalten.
Nein, nochmal, die Verschlüsselung ist nicht perse besser nur weil Symantec, Thawte, Letsencrypt oder der Papst persönlich mein Cert abgenickt hat.
Richtig, die Zertifizierungsstellen verkaufen nur Vertrauen.
|
cosinus
Anmeldungsdatum: 11. Mai 2010
Beiträge: 1374
Wohnort: HB
|
misterunknown schrieb: Das war absolut nicht negativ oder so gemeint ☺
Ok danke, ich hab das "nix Konkretes" als unfreundlich interpretiert 😳
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5358
|
misterunknown schrieb: Da sich noch keiner des eigentlichen Problems angenommen hat:
Doch:
sebix schrieb: Das Problem ist nicht das Vertrauen, sondern dass Chrome den Common Name auch in den Subject Alternative Names haben will. Steht auch so in der Fehlermeldung drinnen.
Und danach noch Verweise auf die Standards mit Zitaten und Erklaerungen.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
sebix schrieb: Doch:
sebix schrieb: Das Problem ist nicht das Vertrauen, sondern dass Chrome den Common Name auch in den Subject Alternative Names haben will. Steht auch so in der Fehlermeldung drinnen.
Und danach noch Verweise auf die Standards mit Zitaten und Erklaerungen.
Hm, stimmt, hab ich überlesen 😳
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2596
Wohnort: Linuxland
|
Hallo Leute, ich hab mich da jetzt den ganzen Tag durch gekämpft und wohl gut 20 mal Zertifikat erstellt. Jetzt natürlich mit der Erweiterung für alternative DNSnamen. Tatsächlich gehts jetzt noch schlechter wie vorher. In allen Browser bis auf Chrome funktioniert es gleich wie vorhin beschrieben. Importiert man das CA wird im Browser das Schloss in der Adressleiste grün. Ganz anders bei Chrome. Dort lässt sich eine Seite mit dem neuen Zertifikat gar nicht mal mehr aufrufen. Fehlemeldung: "Diese Website kann keine sichere Verbindung bereitstellen vdr.osit.cc erfüllt die Sicherheitsstandards nicht. ERR_SSL_SERVER_CERT_BAD_FORMAT" Gut, wie bin ich nun vorgegangen? Ich hab mir aus den Dokuseiten was zusammengebastelt. Muss zugeben das Zertifikatsthema ist komplexer als Anfangs gedacht. Also erstes hab ich mir mal ein Arbeitsverzeichnis in meinem Home eingerichtet. Dort hab ich als erstes die CA generiert.
openssl req -new -x509 -newkey rsa:4096 -keyout cakey.pem -out 01cacert.pem -days 7300
mkdir -p ca/newcerts
touch ca/index.txt
Erstellen der SSL-config:
cat ssl.conf
[ca]
default_ca = CA_default
[CA_default]
dir = ./ca
database = $dir/index.txt
new_certs_dir = $dir/newcerts
serial = $dir/serial
private_key = ./cakey.pem
certificate = ./01cacert.pem
default_days = 7500
default_md = sha256
policy = policy_anything
copy_extensions = copyall
[policy_anything]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[req]
prompt = no
distinguished_name = req_distinguished_name
req_extensions = v3_ca
[req_distinguished_name]
CN = *.osit.cc
[v3_ca]
subjectAltName = @alt_names
[alt_names]
IP.1 = 127.0.0.1
IP.2 = ::1
DNS.1 = localhost
DNS.2 = *.osit.cc
Erstellen des private keys:
openssl genrsa -out key.pem 4096 -days 7500
Erstellen des Certrequests
openssl req -new -config ssl.conf -key key.pem -out ssl.csr
Generieren des Zertifiaktes
openssl ca -config ssl.conf -create_serial -batch -in ssl.csr -out erstescert.pem
Wo ist hier der Fehler am Sicherheitsstandard? Was fehlt mir? Ich hab natürlich mal den Teil mit den IP-Adressen zum Test entfernt. Aber das hatte auch keine Wirkung. lg
Dark Wolf
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6473
|
Dark_Wolf schrieb: Ich hab mir aus den Dokuseiten was zusammengebastelt.
Also ich hab nicht ganz verstanden, was du da gerade tust bzw. nach welchen Anleitungen du vor gehst. Warum nutzt du nicht ▶ CA ? Falls dort was falsch ist kannst du es ja hier schreiben - dann schauen wir wo das Problem ist.
Muss zugeben das Zertifikatsthema ist komplexer als Anfangs gedacht.
Aber es wird doch nicht einfacher, wenn du dir da etwas zusammen bastelst ...
Also erstes hab ich mir mal ein Arbeitsverzeichnis in meinem Home eingerichtet. Dort hab ich als erstes die CA generiert.
openssl req -new -x509 -newkey rsa:4096 -keyout cakey.pem -out 01cacert.pem -days 7300
mkdir -p ca/newcerts
touch ca/index.txt
Äh, nein. openssl req -new erstellt einen Zertifikats Request und keine CA. Weiter hab ich jetzt nicht gelesen. Solange nicht nachvollziehbar ist, nach welchen Schritten du vor gehst, ist es sehr schwierig bis unmöglich, dir hier zu helfen. Gutes neues Jahr.
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2596
Wohnort: Linuxland
|
Ok, danke. Ich mach mir nen LXC und Spiel das mal vom Wiki von Anfang bis Ende durch.
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2596
Wohnort: Linuxland
|
Hallo Leute, bitte entschuldigt die verspätete Rückmeldung. Ist Projekt technisch einfach nicht rein gegangen.
Also ich hab mich exakt an die die CA im Wiki gehalten. Ich hab für nen eigenen LXC installiert. Mit schon ein wenig mehr Erfolg. Also ich hab nun das Zertifikat mit Key installiert. Wie erwartet in Firefox gehts in Google Chrome nicht. Aber die Fehlermeldung in Chrome ist besser als wie beim letzten mal. Man kann die Webseite aufrufen aber das Zertifikat ist ungültig. Ok die SAN Extension fehlt. Aber wie füge ich diese hinzu? Fand in der Datei /usr/lib/ssl/openssl.cnf nichts was darauf hindeuten würde. Zum anderen ist das Zertifikat nur 1 Jahr gültig obwohl in der Datei /usr/lib/ssl/misc/CA.pl 30 Jahre angegeben wurden. Vielen Dank.
glg
Dark Wolf
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5358
|
Dark_Wolf schrieb: Ok die SAN Extension fehlt. Aber wie füge ich diese hinzu? Fand in der Datei /usr/lib/ssl/openssl.cnf nichts was darauf hindeuten würde.
Das wurde dir hier schon erlaeutert, aber du hast die Ratschlaege nur abgeaendert umgesetzt und nicht dargestellt wie du dann vorgegangen bist. Zum anderen ist das Zertifikat nur 1 Jahr gültig obwohl in der Datei /usr/lib/ssl/misc/CA.pl 30 Jahre angegeben wurden.
Die Gueltigkeit des CA-Zertifkats uebertraegt sich nicht automatisch auch auf die der damit unterschriebenen Zertifikate. Das musst du schon extra spezifizierern.
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2596
Wohnort: Linuxland
|
Hallo Leute, nachdem mir noch 7 Tage Zeit bleibe bis alle Zertifikate auslaufen habe ich mich nochmal drann gesetzt. Ich habe alles laut Wikiseite, und zwar absolut exakt laut Wikiseite gemacht. Wie man es auch dreht, das Zertifikat wird nicht vertraut. Egal ob Goolge, oder Firefox. Ich hab den Vorgang mind. 10 mal gemacht und kanns nun im Schlaf. Trotz lokal installiertem CA wird's im Webbrowser nicht grün. Fehlt viel. was in der Anleitung? Nachtrag: Browser muss anscheinend jedes mal neu gestartet werden wenn eine neue CA installiert wird, dann tuts auch. Firefox geht. Chromium/Chrome trotz installierter CA nicht. Nur toll das niemand hier bei uns Firefox verwendet. Weis jemand was Chromium noch benötigt?
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Hast du das Zertifikat korrekt importiert?
chrome://settings/certificates?search=Zertifikate
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2596
Wohnort: Linuxland
|
misterunknown schrieb: Hast du das Zertifikat korrekt importiert?
chrome://settings/certificates?search=Zertifikate
Ja. Habs sogar auf der CMD gemacht:
certutil -d sql:$HOME/.pki/nssdb -A -n '' -i cacert.pem -t TCP,TCP,TCP
CA scheint in Chrome auf. Konqueror, Firefox, usw. funktionieren. Hab auch schon mal zur Sicherheit einen anderen Benutzer verwendet. Leider gleich.
|
Dark_Wolf
(Themenstarter)
Anmeldungsdatum: 12. August 2006
Beiträge: 2596
Wohnort: Linuxland
|
Problem gelöst. Hab mich nun in einigen Artikeln über "subjectAltName" eingelesen. Wird auch von Google hier beschrieben. Die Config "/etc/ssl/openssl.cnf" muss hierfür mit einigen Daten gefüttert werden. Ich werde den Wikieintrag CA dahingehend ergänzen. Problem hatte ich aber trotzdem beim Signieren des Zertifikates. Ich bekam die Fehlermeldung:
failed to update database
TXT_DB error number 2
Wüsste nicht was denn nun doppelt ist. Ich habe die Optionen folgender Maßen ergänzt:
[ v3_req ]
...
subjectAltName = @alt_names
...
[ alt_names ]
DNS.1 = *.osit.cc
DNS.2 = localhost
DNS.3 = ip6-localhost
IP.1 = 127.0.0.1
IP.2 = ::1
...
[ v3_ca ]
...
subjectAltName = @alt_names
...
[ CA_default ]
...
copy_extensions = copy
... Das Problem lies sich umgehen in dem ich die Datei "demoCA/index.txt.attr" bearbeitete und folgendes änderte:
-- unique_subject = yes
++ unique_subject = no glg
Dark Wolf Nachtrag:
Ich kann "copy_extensions = copy" weglassen, dann muss ich das File "demoCA/index.txt.attr", aber dann gibt es im Zertifikat auch die Extension nicht.
|