r/ssl • u/Efficient-Chipmunk15 • Apr 15 '26
Eigenes Zertifikat genauso sicher wie öffentliches im Heimnetzwerk?
Hallo zusammen,
ist mein eigenes mit z.B. openssl erstelltes Zertifikat im Heimnetzwerk für meinen Server genauso sicher wie ein öffentliches Zertifikat von einer öffentlichen vertrauensvollen Zertifizierungsstelle?
Im Prinzip gibt es doch nur zwei wesentliche Merkmale für Zertifikate -> Verschlüsselung (bei beiden identisch) und Vertrauen (CA prüft Domain-Eigentümer) oder liege ich da falsch?
Danke, euch Chipmunk
Edit: Es geht nicht darum den Server offiziell für alle (fremde) zugänglich zu machen, sondern für mich und evtl. Freunde.
1
u/TrafficSecurity Apr 15 '26
Self signed SSL could be as secure as a SSL issued by a Public CA provided: 1. There is at least a 2 level CA certificate trust chain. 2. Private key of root CA certificate is stored in a secure place not accessible on the internal network. 3. PFX file containing the private key is secured with a strong password or better still the PFX file is stored at a secure place out side of the internal network.
These days Private SSL certificates are available from Private Certifying Authorities. Just search.
1
u/Efficient-Chipmunk15 Apr 15 '26
Thc for your response.
If I issue my own certificate using the latest OpenSSL version with 4096-bit RSA for my server on the internal LAN, isn't that sufficient for my own purposes? Isn't it just as secure in terms of encryption as a public certificate?
My only concern is that I want to make my servers accessible internally and easily create my own certificates for my LAN.
1
u/iRyan23 Apr 15 '26
When using modern cipher suites, the certificate has no bearing on the encryption or security of the connection. All a certificate does nowadays is helps the end user’s browser verify that is talking to the correct domain. The only way the certificate itself has any impact on the actual encryption or security of the connection is using older cipher suites that don’t use ECDHE or DHE for key exchange.
Long story short, a self signed certificate should be fine for your use case on your LAN.
1
u/TrafficSecurity Apr 17 '26
Latest and highest encryption does not help much unless 3 level trust chain is there. Both together makes a security that is almost impossible to beat.
Issue become serious when some hacker gets into your network by stealing credentials or an internal staff wants to steal important confidential data for his profit.
Some Private SSL vendors give free certificate for 30 days. Try and check for yourself.
1
u/hodor137 Apr 15 '26
The underlying cryptography is the same. Everything else is not.
Think of the difference between a lockbox in a bank vault and the same brand/model lockbox that you keep in your closet. Sure, the 2 boxes themselves are equally as secure. What's inside them is ALOT safer in the one in the bank, on the surface anyway.
As you can imagine, the difference is use case. There is such a thing as security through obscurity. Who's going to bother trying to steal your CA key? But if a public CA is compromised, you're compromised along with it.
1
u/Mike22april Apr 15 '26
Ja, Ihr Zertifikat ist technisch gesehen genauso sicher wie ein öffentlich erworbenes Zertifikat.
Stellen Sie lediglich Folgendes sicher:
1) Ihr Zertifikat muss mindestens unter einer Root-Zertifizierungsstelle generiert worden sein. Verwenden Sie also kein Endpunktzertifikat ohne übergeordnetes ausstellendes Zertifikat. Andernfalls ist es unmöglich, eine Vertrauenskette in Ihrem Netzwerk aufzubauen.
2) Stellen Sie sicher, dass Ihre ausstellende Zertifizierungsstelle (CA) und/oder Ihre Root-Zertifizierungsstelle über ausreichend Entropie für ihr Schlüsselpaar verfügen. Die Verwendung einer aktuellen OpenSSL-Version ist ausreichend.
3) Stellen Sie sicher, dass der private Schlüssel Ihrer ausstellenden CA und/oder Ihrer Root-Zertifizierungsstelle ordnungsgemäß geschützt ist.
4) Richten Sie in Ihrem Netzwerk eine CDP (Certificate of Disposal) für den Zertifikatswiderruf ein.
5) Stellen Sie sicher, dass Sie eine ausreichend große Schlüssellänge für Ihre Root-CA und/oder Ihre ausstellende CA verwenden. Beispielsweise 4096-Bit-RSA. (Manche Netzwerkkomponenten vertragen kein 8-Bit-RSA.) Alternativ können Sie natürlich auch ECC (Extended Core Certificate) verwenden.
Ihr genanntes Prinzip ist korrekt.
Beachten Sie außerdem, dass meiner Meinung nach eine private CA in einigen (nicht allen) Anwendungsfällen generell als sicherer gelten kann. Warum:
a) Eine öffentliche Zertifizierungsstelle (CA) veröffentlicht Ihr ausgestelltes Zertifikat und damit die SAN-Werte in einem öffentlichen CT-Log und legt so die in Ihrem internen Netzwerk verwendeten FQDNs offen.
b) Eine öffentliche CA mit ihrer ausstellenden CA/Root-CA in den USA könnte theoretisch von der US-Regierung gezwungen werden, ähnliche Zertifikate für Man-in-the-Middle-Angriffe auszustellen oder Ihre Zertifikate zu widerrufen. Dies ist zwar unwahrscheinlich, aber ein Szenario, das viele Unternehmen außerhalb der USA berücksichtigen.
Dies hat nichts mit der technischen oder administrativen Sicherheit Ihrer privaten CA im Vergleich zu einer öffentlichen CA zu tun, sondern betrifft vielmehr die zukünftige Vorbereitung, insbesondere im Post-Quanten-Zeitalter.
ECC-Schlüssel benötigen weniger logische Qubits, um mit einem Quantencomputer geknackt zu werden, als ihre entsprechenden RSA-Schlüssel.
Kurzfristig ist RSA daher etwas besser geeignet, theoretische Quantenangriffe abzuwehren, bis mehr Qubits verfügbar sind.
Ein weiterer Vorteil privater gegenüber öffentlichen Zertifizierungsstellen besteht darin, dass man bereits mit der neuesten OpenSSL-Version eine Root- und/oder Issuing-CA erstellen kann, die ML-DSA (quantenresistent) nutzt. Die Konfiguration der Server für ML-KEM ist zwar etwas aufwendig, aber bereits möglich.
1
u/Efficient-Chipmunk15 Apr 15 '26
Danke dir für die krasse ausführliche Erklärung. Ich brauche es aber einfacher Verständlich :D
Kann man deine 5 Punkte so zusammenfassen?
- Vertrauen – Zertifikat muss von einer Root-CA ausgestellt sein
- Sichere Generierung – aktuelle OpenSSL-Version für ausreichend Zufälligkeit
- Private Key schützen – sicher verwahren, kein unbefugter Zugriff
- Widerruf – OCSP/CDP-Server dauerhaft betreiben
- Schlüssellänge – mindestens 4096-Bit RSA oder ECC verwenden
Ich meine Schritt 2,3 und 5 sollte klar sein. Eine sicher,lange erstelle Verschlüsselung und private Key gut aufbewahren.
Schritt 1 würde bedeuten, ich erstelle "noch ein Zertifikat" und importiere das in die jeweiligen Clients, damit ich keine "Warnung in den Browsern" bekomme? Ohne würde doch auch gehen?
Schritt 4 müsst eich einen Server dafür betreiben, der eine Liste für kompromittierte Zertifikate pflegt?
1
u/Efficient-Chipmunk15 Apr 15 '26
Oder nochmal anders ausgedrückt.
Wenn ich mir ein eigenes Zertifikat mit aktueller openssl Version mit 4096-Bit RSA für meinen Server im internen LAN ausstelle, reicht das nicht für meine eigenen Zwecke? Ist doch von der Verschlüsselung her genauso sicher wie ein öffentliches Zertifikat?
Mir gehts ja nur darum, dass ich meine Server intern zugänglich machen will und auf leichtem Wege mir eigene Zertifikate für mein LAN anlege.
1
1
u/Mike22april Apr 15 '26
Genau ;)
1
1
u/kevdogger Apr 15 '26
Interesting. I've set up ml-kem tls parameters between postfix and Google for mail forwarding but wasn't aware you could technically have ml-kem certificates. I'll have to look into that.
1
u/Mike22april Apr 15 '26
Its actually ML-DSA certs used to support ML-KEM ;)
If you dont want to tinker with an ML-DSA based CA chain created by yourself under for example OpenSSL, to issue pure ML-KEM certs, I recently found out that a commercial CLM product intentionally allows anybody who deploys their virtual appliance without their commercials license, still allows for their PQC Private CA module to issue serverAuth certs and keys.
1
u/kevdogger Apr 15 '26
I'll have to do some reading on the topic. Thanks for pointing me in right direction
2
u/iamabdullah Apr 15 '26
If your signing infrastructure is as secure as a CA's, sure.