Jump to content

Signing-Zertifikat zur Nutzung mit Squid (Transparent Proxy) erstellen


Direkt zur Lösung Gelöst von NilsK,

Empfohlene Beiträge

Guten Tag zusammen,

 

ich brauche ein Zertifikat, welches meine Untergeordnete Zertifizierungsstelle im Netzwerk verwenden kann.

 

Kurz zum Setup:

- Normale Windows Domäne

- Zwei Zertifizierungsstellen im Netzwerk (Windows) vorhanden

    - Eine Root-Zertifizierungsstelle (Stammzertifizierungsstelle des Unternehmens); Offline

    - Eine untergeordnete Zertifizierungsstelle; Ausstellung von Zertifikaten

 

Ich habe einen dedizierten Linux-Server, der künftig als Proxy-Server (Transparent-Modus) laufen soll.

Dieser ist funktional und verwendet derzeit (zu Testzwecken und zur Installation) ein (vom Rechner selbst) selbst-signiertes Zertifikat.

Hintergrund: Die untergeordnete Zertifizierungsstelle prüft die Validität der Herkunft (vgl. Screenshot) was ohne Probleme funktioniert.

Ich würde gerne, z. B. mittels "mmc" einen entsprechenden Zertifikatsrequest erstellen, der es dem Proxy erlaubt, die untergeordnete Zertifizierungsstelle zu nutzen und nicht die "eigene". Wenn ich einfach das Zertifikat der Zertifizierungsstelle im PEM-Format (BASE64) im Proxy hinterlege, terminiert der Start des Dienstes sinngemäß mit "Es liegt kein Signaturfähiges Zertifikat vor". Ich vermute, daher, dass ich bei den Eigenschaften/Erweiterungen verschiedene Angaben machen muss. Das Zertifikat muss in der Lage sein Websites zu identifizieren.

 

PS: Ich könnte auch das selbst-signierte Zertifikat in der Domäne verteilen (das würde ganz sicher auch funktionieren). Lieber würde ich allerdings die vorhandenen Zertifizierungsstellen benutzen.

 

Ich hoffe, ich sorge jetzt nicht für Verwirrung oder bin nicht grundsätzlich auf einem Irrweg unterwegs und bedanke mich schon einmal vorab.

 

  • "mmc.exe" starten
  • Snap-In "Certificates (local computer)" hinzufügen.
  • Unter "Own Certificates" -> All Tasks -> "Extended" -> "Custom Request" und nochmal "Custom" wählen
  • Vorlage "Legacy" "in PKCS #10"
  • Eigenschaften -> Erweiterungen
  • >> An diesem Punkt hänge ich zurzeit <<

Screenshot 2024-11-05 124304.png

Link zu diesem Kommentar

Moin,

 

das ist jetzt alles etwas verworren ... aber leider ist die ganze Zertifikatsklamotte ja auch oft unübersichtlich.

 

Lass uns mal ordnen:

  • Du möchtest ein TLS-Zertifikat für deinen Proxyserver unter Linux, richtig?
  • Du hast eine zweistufige Windows-PKI, die untergeordnete CA kann Zertifikate ausstellen.

 

Um einen CSR für deinen Proxy zu erzeugen, müsstest du das zweckmäßigerweise von diesem Proxy aus tun. Der braucht ja schließlich den privaten Schlüssel. Also ist eine MMC nicht das richtige Werkzeug, denn die läuft ja auf einem Windows-Rechner. Wie du auf deiner Linux-Disto einen CSR erzeugst, musst du in deren Doku nachsehen.

 

Den CSR kopierst du dann (im einfachsten Fall) als Datei auf die CA und erzeugst dafür ein Zertifikat. Das exportierst du in eine Datei und kopierst diese auf deinen Proxy. Wie du sie dort so hinterlegst, dass die Proxy-Software sie auch findet, musst du in der Doku der Software nachsehen. Ob du die Zeritifkatskette auch hinterlegen musst, sollte ebenfalls aus der Proxy-Doku hervorgehen. Meist ist das aber nicht nötig und der Client muss das dann prüfen.

 

Gruß, Nils

 

bearbeitet von NilsK
Link zu diesem Kommentar

Hey Nils,

 

Du hast natürlich recht, etwas verworren geschrieben, allerdings habe ich lange über den Text nachgedacht. Aber ich denke mit Deinem Kommentar (danke dafür) hast Du das ja gerade gerückt. Allerdings glaube ich, dass Du korrekt erkannt hast, was ich benötige. Meine Konfigurationsdatei (auf dem Proxy-Server sieht aktuell so aus; *.cnf). Hiermit fordere ich ein SAN-Zertifikat an (typischerweise für einen Webserver). Eventuell muss ich hier nur einen weiteren Eintrag unter "keyUsage" vornehmen? Kann das sein?

 

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
C = DE
ST = xxx
L = xxx
O = xxx
OU = xx
CN = {servername}.{dns-suffix}

[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
IP.1 = {servern-ip}
DNS.1 = {servername}.{dns-suffix}
DNS.2 = *.{Zusätzliche Domains}
DNS.3 = *.{servername}.{dns-suffix}

 

Im Anschluss kann ich mit dieser Datei die Request-Datei erstellen...

openssl req -new -out {servername}.csr -key {servername}.key -config {servername}.cnf

 

Um diese dann zu verwenden um das korrekte Zertifikat zu erzeugen. Oder reicht das tatsächlich so aus?

Link zu diesem Kommentar

Moin,

 

vor 5 Minuten schrieb Dukel:

Du wirst ein Zertifikat für eine untergeordnete CA brauchen.

warum sollte er das brauchen? Er will doch gar keine untergeordnete CA einrichten, sondern einen Proxyserver.

 

Oder überseh ich da was?

 

Zitat

Eventuell muss ich hier nur einen weiteren Eintrag unter "keyUsage" vornehmen?

 

Nein, die Angabe ist doch schon richtig, es soll ja ein ServerAuth-Zertifikat sein.

 

Gruß, Nils

 

bearbeitet von NilsK
Link zu diesem Kommentar
Gerade eben schrieb NilsK:

Moin,

 

warum sollte er das brauchen? Er will doch gar keine untergeordnete CA einrichten, sondern einen Proxyserver.

 

Oder überseh ich da was?

 

Gruß, Nils

 

Korrekt... Ich bestücke den Proxy-Server mit dem Zertifikat. Der scannt alle Webseiten. Ich habe mal das vorhanden Webserver-Zertifikat eingesetzt und bekomme den Fehler: 

Beim Verbinden mit www.google.de trat ein Fehler auf. Eine Verwendung des Zertifikatschlüssels ist für den versuchten Arbeitsschritt unpassend.

Fehlercode: SEC_ERROR_INADEQUATE_KEY_USAGE

Link zu diesem Kommentar

Sorry für die Verwirrung, Leute. Gemäß der u. g. Tabelle verwende ich Bit 2 und 3. Ich vermute ich muss Bit 5 mit anfordern... Checke das mal!

 

Bit Hex Description Label
8 0x0 decipherOnly Decrypt only, in conjunction with keyAgreement
7 0x1 encipherOnly Encrypt only, in conjunction with keyAgreement
6 0x2 cRLSign Signing blacklists
5 0x4 keyCertSign Signing certificates
4 0x8 keyAgreement Used, for example, for data encryption with the Diffie-Hellman method
3 0x10 dataEncipherment Data encryption, directly with the key contained in the certificate
2 0x20 keyEncipherment Key encryption, i.e. when a symmetric key is used for data encryption and this is encrypted with the key contained in the certificate
1 0x40 nonRepudiation Non-repudiation
0 0x80 digitalSignature Digital signature
Link zu diesem Kommentar
  • Beste Lösung

Moin,

 

das ist ja das, was ich bislang erfolglos aus dem TO rauszukriegen versuche. :lol3: Ob er sowas machen möchte, hat er bislang ja noch nicht gesagt. In dem Fall wäre es aber eher üblich, mit dem selbstsignierten Zertifikat zu arbeiten, als eine CA einzuspannen.

 

Gruß, Nils

 

bearbeitet von NilsK
Link zu diesem Kommentar

Es ist schwierig die richtigen Fragen zu stellen oder zu antworten, wenn man selbst nicht so 100%tig im Thema ist. Ja, es geht darum dynamisch SSL-Zertifikate auszustellen. Wenn es üblich ist hierbei mit einem selbstsignierten Zertifikat zu arbeiten, funktioniert der Proxy-Server jetzt korrekt und dieser Thread ist gelöst. Ich hatte nur angenommen, dass ich die CA auf dem Proxy-Server durch die Unternehmens-CA ersetzen könnte. So kann ich das vorhandene Server-Zertifikat jetzt in die GPO einbinden und in der Domäne verteilen.

Link zu diesem Kommentar
vor 12 Minuten schrieb captncrunch:

Es ist schwierig die richtigen Fragen zu stellen oder zu antworten, wenn man selbst nicht so 100%tig im Thema ist. Ja, es geht darum dynamisch SSL-Zertifikate auszustellen. Wenn es üblich ist hierbei mit einem selbstsignierten Zertifikat zu arbeiten, funktioniert der Proxy-Server jetzt korrekt und dieser Thread ist gelöst. Ich hatte nur angenommen, dass ich die CA auf dem Proxy-Server durch die Unternehmens-CA ersetzen könnte. So kann ich das vorhandene Server-Zertifikat jetzt in die GPO einbinden und in der Domäne verteilen.

 

Wie schon geschrieben brauchst du ein Sub-CA-Zertifikat.

Außerdem würde ich das Zertifikat von der Root CA unterschreiben lassen und nicht von der Unternehmens CA.

 

Link zu diesem Kommentar

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...