SSL mit LetsEncrypt auf eigenen Server
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
ahnung
apache
beurteilen
code
datei
eins
fakt
frage
info
installieren
kommentar
log
machen
ordner
pfad
server
sinn
untersuchen
url
zertifikat
-
Hallo :)
ich hoffe ihr könnt mir in diesem Fall helfen oder mir ein paar Tipps geben.
Hier bei Lima gibt es ja ein kostenloses SSL Zertifikat, das auch wunderbar funktioniert.
Ich habe aber noch einen eigenen Server von Kimsufi, was ja zu OVH gehört.
Auf diesem Server läuft nur owncloud, das mit Apache2 läuft. Der Apache2 Server kann ja selbst SSL-Zertifikate erstellen, aber jeder Browser gibt ja immer die Gefahrenmeldung heraus, das die Website nicht sicher ist. Wenn ich mal Dateien share, kommt immer mal wieder von Kumpels die Frage, wie die Verbindung ist nicht sicher bla bla...
Nunja, fix im Internet geschaut, hab ich gesehen das man "einfach" ein LetsEncrypt Zertikat mit dem Programm Certbot installieren kann, man hat nur kurz über https://certbot.eff.org/ den Webserver und OS angeben müssen, dann kam eine kurze Dokumentation, die ich dann ausgeführt habe, bis die Erfolgsmeldung kam, das alles erstellt wurde.
Unter /etc/apache2/ssl finde ich meine .crt & .key Datei, doch irgendwie will das ganze nicht...
Unter /etc/apache2/sites-enabled/ finde ich dann meine .conf. Dort ist auch der Pfad zu den Zertifikaten angegeben.
Wenn ich https://www.ssllabs.com/ssltest/ laufen lasse, kommt die Note "T" in Rot..
Apache-Server wurde auch neu gestartet.
Habt ihr irgendwelche Tipps, wonach ich mal schauen könnte?
Auf dem Server läuft Debian8 mit Apache2 und ownloud mit der Version 9 läuft über domain.de/owncloud. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Es wäre hilfreich, wenn du den Link zu deiner Website posten könntest.
(Man kann in Firefox und Chrome Informationen zum Zertifikat ansehen - über den linken "Info"-Button neben der Adressleiste - und evtl. ist es ja nicht richtig hinterlegt.)
PS: "PHP, MySQL & .htaccess" ist nicht passende Forum. "Homepage Allgemein" oder "Betriebssysteme" würde eher passen ... -
lopayne schrieb:
Unter /etc/apache2/ssl finde ich meine .crt & .key Datei, doch irgendwie will das ganze nicht...
Unter /etc/apache2/sites-enabled/ finde ich dann meine .conf. Dort ist auch der Pfad zu den Zertifikaten angegeben.
https://certbot.eff.org/docs/using.html#where-are-my-certificates
Die schreiben aber das die certificate woanders liegen, hast du die kopiert?
zudem lassen sich mit:
$ openssl x509 -in example.com.pem -text
recht gut anzeigen. -
strlcp schrieb:
Die schreiben aber das die certificate woanders liegen, hast du die kopiert?
Ich kann aus Erfahrung sagen, dass die Zertifikate normalerweise auch unter NGINX und Apache eingetragen werden (man kann entweder NGINX oder Apache als Option angegeben oder sie werden nicht eintragen, je nachdem, was man auswählt)
Der Pfad zu den Zertifikaten wird dabei in der jeweiligen vHost bzw. Config-File der Domain hinterlegt.
Siehe:
https://certbot.eff.org/docs/using.html#apache
https://certbot.eff.org/docs/using.html#nginx -
webfreclan schrieb:
strlcp schrieb:
Die schreiben aber das die certificate woanders liegen, hast du die kopiert?
Ich kann aus Erfahrung sagen, dass die Zertifikate normalerweise auch unter NGINX und Apache eingetragen werden (man kann entweder NGINX oder Apache als Option angegeben oder sie werden nicht eintragen, je nachdem, was man auswählt)
Der Pfad zu den Zertifikaten wird dabei in der jeweiligen vHost bzw. Config-File der Domain hinterlegt.
Siehe:
https://certbot.eff.org/docs/using.html#apache
https://certbot.eff.org/docs/using.html#nginx
Hey,
dachte mir antwortet nie jemand, aber wenn ich es im falschen Forum gepostet habe, kein wunder
Das hatte ich natürlich vergessen, https://rlopane.de ist meine Adresse, /owncloud ist dann mein Cloudserver.
Im Apache-Forum unter Sites-enabled steht in der Config "rlopane.de.conf" folgendermaßen:
<VirtualHost *:443> DocumentRoot /var/www/owncloud ServerName rlopane.de Header always add Strict-Transport-Security "max-age=15768000; includeSubDomains; preload" SSLEngine on SSLCertificateFile /etc/letsencrypt/live/rlopane.de/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/rlopane.de/privkey.pem </VirtualHost>
So wie ich das sehe ist der Pfad doch richtig hinterlegt, oder täusche ich mich da.
In dem Ordner befinden sich die Daten:
cert.pem chain.pem fullchain.pem privkey.pem
& falls hier noch die Log-Datei von letsencrypt, habe vorhin das Zertifikat neu installieren lassen, aber nicht erneuert.
2016-09-27 21:04:18,258:DEBUG:certbot.main:Root logging level set at 30 2016-09-27 21:04:18,263:INFO:certbot.main:Saving debug log to /var/log/letsencrypt/letsencrypt.log 2016-09-27 21:04:18,266:DEBUG:certbot.main:certbot version: 0.8.1 2016-09-27 21:04:18,267:DEBUG:certbot.main:Arguments: ['--apache'] 2016-09-27 21:04:18,271:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone) 2016-09-27 21:04:18,283:DEBUG:certbot.plugins.selection:Requested authenticator apache and installer apache 2016-09-27 21:04:20,184:DEBUG:certbot.plugins.selection:Single candidate plugin: * apache Description: Apache Web Server - Alpha Interfaces: IAuthenticator, IInstaller, IPlugin Entry point: apache = certbot_apache.configurator:ApacheConfigurator Initialized: <certbot_apache.configurator.ApacheConfigurator object at 0x68a0616b9390> Prep: True 2016-09-27 21:04:20,190:DEBUG:certbot.plugins.selection:Selected authenticator <certbot_apache.configurator.ApacheConfigurator object at 0x68a0616b9390> and installer <certbot_apache.configurator.ApacheConfigurator object at 0x68a0616b9390> 2016-09-27 21:04:24,807:DEBUG:certbot.main:Picked account: <Account(1bbdaa92e0d48351b2688dbaee904c24)> 2016-09-27 21:04:24,814:DEBUG:root:Sending GET request to https://acme-v01.api.letsencrypt.org/directory. args: (), kwargs: {} 2016-09-27 21:04:24,866:INFO:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org 2016-09-27 21:04:25,620:DEBUG:requests.packages.urllib3.connectionpool:"GET /directory HTTP/1.1" 200 280 2016-09-27 21:04:25,625:DEBUG:root:Received <Response [200]>. Headers: {'Content-Length': '280', 'Expires': 'Tue, 27 Sep 2016 21:02:43 GMT', 'Boulder-Request-Id': '2wk14990DHqhnqVcFWVgjZTpBfS-H2wiVjsEmO7ClgQ', 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Tue, 27 Sep 2016 21:02:43 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', 'Replay-Nonce': 'tdeiTyR75fejbHNYuavy-qjz4sixvfFhaWm3nfl-wGo'}. Content: '{\n "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"\n}' 2016-09-27 21:04:25,626:DEBUG:acme.client:Received response <Response [200]> (headers: {'Content-Length': '280', 'Expires': 'Tue, 27 Sep 2016 21:02:43 GMT', 'Boulder-Request-Id': '2wk14990DHqhnqVcFWVgjZTpBfS-H2wiVjsEmO7ClgQ', 'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx', 'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control': 'max-age=0, no-cache, no-store', 'Date': 'Tue, 27 Sep 2016 21:02:43 GMT', 'X-Frame-Options': 'DENY', 'Content-Type': 'application/json', 'Replay-Nonce': 'tdeiTyR75fejbHNYuavy-qjz4sixvfFhaWm3nfl-wGo'}): '{\n "new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz",\n "new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert",\n "new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg",\n "revoke-cert": "https://acme-v01.api.letsencrypt.org/acme/revoke-cert"\n}' 2016-09-27 21:04:25,643:DEBUG:parsedatetime:parse (top of loop): [30 days][] 2016-09-27 21:04:25,676:DEBUG:parsedatetime:CRE_UNITS matched 2016-09-27 21:04:25,678:DEBUG:parsedatetime:parse (bottom) [][30 days][][] 2016-09-27 21:04:25,678:DEBUG:parsedatetime:weekday False, dateStd False, dateStr False, time False, timeStr False, meridian False 2016-09-27 21:04:25,678:DEBUG:parsedatetime:dayStr False, modifier False, modifier2 False, units True, qunits False 2016-09-27 21:04:25,679:DEBUG:parsedatetime:_evalString(30 days, time.struct_time(tm_year=2016, tm_mon=9, tm_mday=27, tm_hour=21, tm_min=4, tm_sec=25, tm_wday=1, tm_yday=271, tm_isdst=0)) 2016-09-27 21:04:25,679:DEBUG:parsedatetime:_buildTime: [30 ][][days] 2016-09-27 21:04:25,679:DEBUG:parsedatetime:units days --> realunit days 2016-09-27 21:04:25,680:DEBUG:parsedatetime:return 2016-09-27 21:04:25,680:INFO:certbot.renewal:Cert not yet due for renewal 2016-09-27 21:04:48,814:INFO:certbot_apache.configurator:Deploying Certificate to VirtualHost /etc/apache2/sites-available/rlopane.de.conf 2016-09-27 21:04:48,818:DEBUG:certbot_apache.configurator:Apache version is 2.4.10 2016-09-27 21:04:55,160:WARNING:certbot.client:Enhancement redirect was already set.
-
das certificat das der server ausliefert ist jedenfalls das deinige:
gültig ist es noch bis 2026, unterzeichnet von dir. -
Also bei mir wird im Browser nur ein selbst zertifiziertes Zertifikat angezeigt. Bei Zertifikaten von Let's Encrypt wird aber Let's Encrypt (bzw. Let's Encrypt Authority ...) auch als Aussteller angezeigt.
https://rlopane.de/
Der Zertifikat-Aussteller der Gegenstelle wurde nicht erkannt.
HTTP Strict Transport Security: false
HTTP Public Key Pinning: false
Zertifikatskette:
-----BEGIN CERTIFICATE----- MIICujCCAaKgAwIBAgIJALwumSctKqMOMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNV BAMMCnJsb3BhbmUuZGUwHhcNMTYwNDExMDYxOTQxWhcNMjYwNDA5MDYxOTQxWjAV MRMwEQYDVQQDDApybG9wYW5lLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxnX1jU0USs9PPDcNGob/sbmyEqpoVAnJN3cGlpk1S27bPntmQ0wMic1a Xr9bhZCPEPmAIOaQid6r+FSaS3kzGbfkEcksqAjPMjxmQXq2z2/LZFZyvK9svNjP tfp5uwvoTURPqoSLwuAelsEFdzyr+D1ESjmwBT38lo+9KxILFtjRwPzfz4XsUrfh qf8VoqpELV7K3Atadd/IaZBGPU2qak95bxeHXH8nUVQ/cd9Qal+Cca1dcopsZTcj drF8kipjxOESuDQNjOl44VOD7cDLK4LsPRklXe6ZwKTIWuxscFYlsuF7se3yuhT7 dlb+qnDG8xGmGmmyALMr8ArWYwkkowIDAQABow0wCzAJBgNVHRMEAjAAMA0GCSqG SIb3DQEBCwUAA4IBAQBDuyPogr2jlI1DmuJVJE40RNyKlUo0WqY8fq/SlukNojVe 0W+9v+dDk6A78SEjolQu1xmqluZOmS/DCf4IwXYCfWWyV0e8cnAjr0m3wYxUKBFI 6pCiNTaixLNJqItlgo5MeSScogJWKJR9dc04CjHHArGJi6IDCBcCkb2VocMaWKN+ Epb3a6YUK+qy2e7y/psiHA7hwFcwVHra2FeFRR7U2jlP8ewLQlp3sNgTfNjYC/V2 I0Y3r4hZoCmTVsoMGu/zvwXmiq6fKNpNiWFdmbdRq8vDST0m19PoDmFFd5iwyIqF QjZ8KVwKoklHQMwAZ53Hn3HMdgvaQHUKPxVLwQd8 -----END CERTIFICATE-----
Hast du vielleicht noch irgendwo - vielleicht in der apache.conf / httpd.conf / etc - ein altes Zertifikat hinterlegt?
-
Unter /etc/apache2/ssl finde ich meine .crt & .key Datei, doch irgendwie will das ganze nicht...
Unter /etc/apache2/sites-enabled/ finde ich dann meine .conf. Dort ist auch der Pfad zu den Zertifikaten angegeben.
2016-09-27 21:04:48,814:INFO:certbot_apache.configurator:Deploying Certificate to VirtualHost /etc/apache2/sites-available/rlopane.de.conf
SSLCertificateFile /etc/letsencrypt/live/rlopane.de/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/rlopane.de/privkey.pem
Da sind d´Deine Posts inkonsitent!
Und danke fürs ausführlichere Erklären @webfreclan
-
strlcp schrieb:
[...]
Passt doch.
Die Zertifikate werden nach "/etc/letsencrypt/live/rlopane.de/" gespeichert und für den VirtualHost "/etc/apache2/sites-available/rlopane.de.conf" geschrieben. So stehts im Log.
Interessant ist eher die Zeile:
INFO:certbot.renewal:Cert not yet due for renewal
Ich kenne den Client jetzt nicht im Detail. Ein These wäre aber:
Dein eigenes Zertifikat gilt ja noch bis 2026. Let's encrypt sieht also keinen Grund sich ein neues Zertifikat auszustellen und packt deswegen dein altes rein.
Schmeiß doch testweise mal dein Zertifikat raus bzw. tausche es gegen eines aus, welches in 4-5 Tagen auslaufen würde.
Beitrag zuletzt geändert: 29.9.2016 14:20:20 von muellerlukas -
muellerlukas schrieb:
strlcp schrieb:
[...]
Passt doch.
Die Zertifikate werden nach "/etc/letsencrypt/live/rlopane.de/" gespeichert und für den VirtualHost "/etc/apache2/sites-available/rlopane.de.conf" geschrieben. So stehts im Log.
Ja, den habe ich ja zittiert.
Dass im ersten Post was anderes steht, wollte ich nur der Vollständigkeit halber erwähnen.
muellerlukas schrieb:
Interessant ist eher die Zeile:
INFO:certbot.renewal:Cert not yet due for renewal
Ich kenne den Client jetzt nicht im Detail.
Macht nichts, direkt über dem Log steht ein Kommentare des TE:
& falls hier noch die Log-Datei von letsencrypt, habe vorhin das Zertifikat neu installieren lassen, aber nicht erneuert.
Zudem ist es unwahrscheinlich, dass Certbot ein self-signed (nicht das temporäre von certbot, sondern ein "fremdes") in den eigenen Ordner verschiebt.
Aber nichts ist unmöglich.
Beitrag zuletzt geändert: 29.9.2016 15:19:05 von strlcp -
Beim ersten Punkt hast du natürlich recht. Allerdings auch logisch dass der Pfad anders ist. Ist ja auch dokumentiert dass der Client die Konfig ändert. Also eher ein "vorher-nacher" statt "inkosistent".
Zudem ist es unwahrscheinlich, dass Certbot ein self-signed (nicht das temporäre von certbot, sondern ein "fremdes") in den eigenen Ordner verschiebt.
Aber nichts ist unmöglich.
Eher kopieren.
Fakt ist: Der Client ändert den Pfad in der Apache-Konfig. Und wie soll Apache jetzt auf das Zertifikat zugreifen, wenn es nicht in den neuen Pfad kopiert wird?
Fakt ist auch: Der Apache liefert das alte Zertifikat aus.
Ergo: In genannter Datei ist das alte Zertifikat.
Das macht in gewisser Weise auch Sinn: Der TO lässt den Client rennen, der erkennt dass das Zertifikat noch länger als 30 Tage (siehe Log) gültig ist. Also wird zwar die Einrichtung vorgenommen, aber kein neues Zertifikat installiert.
Was hätte der Client auch für einen Grund das Zertifikat zu ersetzen? Er weiß nur dass es aktuell ist. Ob es "gültig" ist kann er nicht beurteilen. Also bleibt es eben.
Ich kenne den Client jetzt nicht im Detail.
Macht nichts, direkt über dem Log steht ein Kommentare des TE:
& falls hier noch die Log-Datei von letsencrypt, habe vorhin das Zertifikat neu installieren lassen, aber nicht erneuert.
Muss ich deinen Kommentar zu meiner Aussage verstehen? Was hat das Log oder der Kommentar vom TO damit zu tun dass ich den Client im Detail nicht kenne bzw. was soll das daran ändern? Das Log sagt einigermaßen _was_ der Client macht, aber erklärt nicht warum und wie.
Oder war das wieder ein "Hauptsache dagegen sein" von dir?
-
Wenn Du den Eingangspost liesst, es steht da recht eindeutig.
Wo Du ein vorher nachher herhaben willst, ich kann es anhand des Eingangspost nicht erkennen.
Ich habe den Certbot nie mit einem plugin betrieben, da stimmt.
Es macht wenig Sinn, nur die Anlaufzeit eines Certificates zu untersuchen, die Certchain ist midenstens genauso wichtig. Wieso soll man die Certification chain nicht untersuchen können:
Ob es "gültig" ist kann er nicht beurteilen.
Deswegen macht für mich keinen Sinn, wenn ein self-signed Cert in den Letsencrypt Ordner kopiert wird.
Oder war das wieder ein "Hauptsache dagegen sein" von dir?
Eine letzte Diffamierung?
Auch gut; as you know: in weniger als 24h bin ich hier abgemeldet; war es da wirklich notwendig, mir unlautere Motive zu unterstellen, anstatt sich mit meinem Punkt auseinderzusetzen?
Ich finde interessant, dass Du bei Deinem Fakt ist nicht mal auf die Idee kommst, ach lassen wir das
Beitrag zuletzt geändert: 29.9.2016 20:14:13 von strlcp -
strlcp schrieb:
Wenn Du den Eingangspost liesst, es steht da recht eindeutig.
Wo Du ein vorher nachher herhaben willst, ich kann es anhand des Eingangspost nicht erkennen.
Wahrscheinlich wegen [Eingangspost] [Client laufen lassen] [Andere Konfig].
Ich hbe den Certbot nie mit einem plugin betrieben, da stimmt.
Wieso Plugin?
Es macht wenig Sinn, nur die Anlaufzeit eines Certificates zu untersuchen, die Certchain ist midenstens genauso wichtig.
Und wie soll der Client die Certchain untersuchen? Das selbst signierte Zertifikat kann doch genauso auf anderen Rechnern akzeptiert sein?
Oder war das wieder ein "Hauptsache dagegen sein" von dir?
Eine letzte Diffamierung?
Auch gut; as you know: in weniger als 24h bin ich hier abgemeldet; war es da wirklich notwendig, mir unlautere Motive zu unterstellen, anstatt sich mit meinem Punkt auseinderzusetzen?
Ich finde interessant, dass Du bei Deinem Fakt ist nicht mal auf die Idee kommst, ach lassen wir das
Ich diffamiere dich nicht. Ich frage nach. Aber wie es klar war: Zu meiner Frage kommst du nicht, du willst nur recht haben. -
plugin:
https://certbot.eff.org/docs/using.html#apache
oder aber:
Discovered plugins:PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
Das selbst signierte Zertifikat kann doch genauso auf anderen Rechnern akzeptiert sein?
ich ging davon aus, das es dem certbot reicht zu erfahren, es ist nicht überall gültig.
da man davon ausgehen kann, das keine ca ihre rechner mit let's encrypt versieht, ist ein self-singed immer suboptimal.
ersetzen:
self-singed
kopieren:
wieso sollte certbot ein nicht valides oder nur ein nicht let's encrypt insrallieren?
Dein ergo ist nicht schlüssig, falsche config, kein neustart etc.
-> fehlende eindeutigkeit.
worauf genau bin ich ncht eingegangen?
Und wie soll Apache jetzt auf das Zertifikat zugreifen, wenn es nicht in den neuen Pfad kopiert wird?
Ich als certbot entwiklmer würde erst schauen, ob ich ein certificat im pfad habe, wenn nicht oder dies nearly outdated ist, mir eins hohlen.
wenn das alles geklappt hat, würde ich die config umschreiben.
Ich schau mir aber nicht die quellen an, um das zu verifizieren.
ich halte meine argumente für schlüssiger aber nicht für evident.
wie schon woanders wo wir beide verschiedener Meinung waren:
lassen wir das, der TE wird es richten.
Beitrag zuletzt geändert: 29.9.2016 21:44:29 von strlcp -
Ein "Plugin" welches per Standard genutzt wird ist kein "plugin".
Was ist für dich "überall gültig", "valide"?
Und als "certbot entwiklmer" willst du WIE nachvollziehen ob die CA ok ist oder nicht?
Sorry, du hast einfach keine Ahnung wie SSL abläuft.
Du würdest also ein Zertifikat, welches dir nicht bekannt ist als "ungültig" abstempeln und gegen ein anderes ersetzen? Na danke.
Du schuldest mir allerdings immer noch eine Antwort auf meine Frage. -
welche frage?
würde der herr sie nochmal formulieren?
wiso standarmäsig genuzt?
ein plugin hat was mit software architektur zu tun imho.
https://de.wikipedia.org/wiki/Plug-in
ja, ich würde die alten certs lassen wo sie sind und die neuen dahinlegen wo sie hingehören.
was ist daran falsch?
ein valides cert?
ein das nicht revoked ist und sich von validen certs ableiten lässt.
anfag der chain ist eine ca.
so wird es auch bei dem programm openssl bezeichnet.
danke, daß du mir jegliche ahnung abstreitest; ich tue das bei dir nicht, auch wenn ich manches
sonderbar finde was du posted.
achja,
akira und ghost in the shell
sind gerade im anime thread gelöscht worden.
keine ahnung wieso.
-
strlcp schrieb:
welche frage?
würde der herr sie nochmal formulieren?
Werde ich nicht. Hoch scrollen darfst du selbst.
wiso standarmäsig genuzt?
Weil der Client nun mal den Apache-Support mitbringt.
ja, ich würde die alten certs lassen wo sie sind und die neuen dahinlegen wo sie hingehören.
was ist daran falsch?
DU hast den Client den der TO nutzt aber nicht programmiert. Es ist unwichtig wie du es machen würdest.
ein valides cert?
ein das nicht revoked ist und sich von validen certs ableiten lässt.
anfag der chain ist eine ca.
so wird es auch bei dem programm openssl bezeichnet.
danke, daß du mir jegliche ahnung abstreitest; ich tue das bei dir nicht, auch wenn ich manches
sonderbar finde was du posted.
Ich spreche dir nur die Ahnung von SSL ab. Und das hast du damit selbst bewiesen. Am Anfang eines Zertifikats steht IMMER eine CA. Valide ist es, wenn der Client das öffentliche Zertifikat oder eins mit dem das Zertifikat unterschrieben ist akzeptiert. "Das valide Zertifikat" gibt es also schlicht nicht. Und der Client kann auch nicht wissen wo das Zertifikat akzeptiert wird, also kann er auch nicht beurteilen ob es valide, gültig, whatever ist.
achja,
akira und ghost in the shell
sind gerade im anime thread gelöscht worden.
keine ahnung wieso.
Dann frag beim zuständigen Moderator nach anstatt das völlig zusammenhanglos in einem anderen Thread zu posten. Niemand wird nach einer Beitragslöschung in anderen Threads suchen.
-
ich gebe zu, ich habe mich inkorrekt ausgedrückt:
am anfang steht eine root-ca, in der regel.
es lassen sich auch private chains bauen, wie du ja angedeutet hast.
ein x509 welches als purpose cert singing hat ist eine certfication authority (streng genommen).
als zusätzliche lektüre rate ich dir das gute alte rfc
https://www.ietf.org/rfc/rfc5280.txt
inwiefern der rest deiner entgegnungen sinn macht überlasse ich dir selbst,
bei openssl und der definition eines plugin haste dich jedenfalls ordentlich in die nesseln gesezt.
wieso dir die entgegnung was hätte sagen müssen?
hättest du möglicherweise gemerkt, hättest du sie im zitat nicht verstümmelt.
jo fahrradkette. -
strlcp schrieb:
als zusätzliche lektüre rate ich dir das gute alte rfc
https://www.ietf.org/rfc/rfc5280.txt
Mir ist das RFC-Dokument sehr gut bekannt, danke.
Da du aber offensichtlich (nicht nur in den Posts, bei der PM-Diskussion* ebenso.) nicht in der Lage bist auf meinen Text und die Argumente darin einzugehen klinke ich mich langsam aus und freue mich, wenn du aufgrund deines Egos verschwunden bist. :)
* Mehr als "VPN ist besser", "SSH-Tunnel ist unsicher" und Anzweiflung technischer Tatsachen kamen da nicht. Beispiele: Windows-Dienst als andere User betreiben, kein extra Interface bei SSH-Tunnels, Zertifikatsspeicher. Nachdem ich dir erklärt habe wie das funktioniert kamen auch nur Kommentare wie "Die Diskussion ist nicht zielführend". -
muellerlukas schrieb:
Valide ist es, wenn der Client das öffentliche Zertifikat oder eins mit dem das Zertifikat unterschrieben ist akzeptiert. "Das valide Zertifikat" gibt es also schlicht nicht. Und der Client kann auch nicht wissen wo das Zertifikat akzeptiert wird, also kann er auch nicht beurteilen ob es valide, gültig, whatever ist.
Wie soll ich dir da antworten?
oder eins mit dem das Zertifikat unterschrieben ist
wie willst du bei x509 mehrere issuer angeben?
die ganze chain muss valide sein.
das öffentliche Zertifikat
was ist ein privates x509 ?
wo gibt es private x509?
wieso sehe ich als user nie fremde private x509?
"Das valide Zertifikat" gibt es also schlicht nicht.
das sag mal den ssl leuten.
https://en.wikipedia.org/wiki/X.509#Certificate_chains_and_cross-certification
ich lade mir dann ab und an das runter:
https://packages.debian.org/jessie/ca-certificates
während meines updates, und entscheide dadurch, ob es valide ist oder eben nicht.
die meisten machen das so, das ist der sinn von hirachischen systemen.
Ich weiss nicht, wo Du die sachlichen Argumente vermisst; ich halte meinen Anregungen für erwähnenswert.
Ich weiss, ich wollte schon weg sein.
Wird noch nichts draus, sorry; dauert aber nicht mehr lang.
Beitrag zuletzt geändert: 1.10.2016 16:54:54 von strlcp -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
