Cloud & Container

Migration von RSA 4096 nach ECDSA 256 Bit und Upgrade der Root / Intermediate CA

DACHS IT Logo By DACHS IT, Team
am

In diesem Artikel berichten wir, wie wir den Wechsel von RSA 4096 zu ECDSA 256 Bit durchgeführt haben, um die Sicherheit und Effizienz unserer Services zu verbessern. Dazu haben wir eine Schritt-für-Schritt-Anleitung erstellt: von der Generierung von EC Schlüssel über die Erstellung von CSR bis zur Integration in Kubernetes-Cluster.

Heute berichten wir über einen wichtigen Schritt in unserer Infrastruktur: die Migration von RSA 4096 zu ECDSA 256 Bit und das Upgrade auf einen neuen Root / Intermediate CA, die ECDSA verwendet. Diese technischen Anpassungen zielen darauf ab, die Sicherheit und Effizienz unserer Zertifikate zu verbessern.

Warum ECDSA?

ECDSA (Elliptic Curve Digital Signature Algorithm) ist in modernen Anwendungen weit verbreitet, da es bei geringerem Bit-Level eine höhere Sicherheit bietet als herkömmliche RSA-Schlüssel. Während wir bisher RSA 4096 Schlüssel verwendet haben, profitieren wir mit ECDSA 256 Bit von kürzeren Schlüsseln, die gleichermaßen sicher, aber schneller zu verarbeiten sind.

Schritte zur Erstellung eines ECDSA-256 CSRs

Mit den nachfolgenden Schritten generieren wir zunächst eine Zertifikatsanforderung (Certificate Signing Request oder kurz CSR) mit ECDSA 256 Bit und SHA-256.

Schritt 1: Erzeugen des privaten Schlüssels

Zuerst generieren wir den privaten ECDSA-Schlüssel unter Verwendung der Kurve prime256v1.

openssl ecparam -name prime256v1 -genkey -noout -out com.cuegee.key.pem

Optional: Weitere Schlüsselinformationen einsehen

Zur Anzeige detaillierter Informationen über den privaten EC-Schlüssel führen wir diesen Befehl aus:

openssl ec -in com.cuegee.com.key.pem -text -noout

Schritt 2: Erstellen der OpenSSL-Konfigurationsdatei

Damit OpenSSL den CSR erstellen kann, benötigen wir eine Konfigurationsdatei (req.cnf), um Details wie SANs (Subject Alternative Names) und die E-Mail-Adresse korrekt einzubeziehen.

Hier ist unsere req.cnf:

[ req ]
default_bits       = 256
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt             = no

[ req_distinguished_name ]
C            = DE
ST           = NW
L            = Duesseldorf
O            = cuegee it gmbh
CN           = cuegee.com
emailAddress = noreply@cuegee.com

[ req_ext ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment
# subjectAltName = @alt_names

# [ alt_names ]
# DNS.1   = example.com
# DNS.2   = www.example.com

Schritt 3: Generieren des CSR

Nun generieren wir die CSR mit der erstellten Konfigurationsdatei:

openssl req -new -key com.cuegee.key.pem -out com.cuegee.csr.pem -config req.cnf

Optional: Überprüfen der CSR

Zur Überprüfung des Inhalts Ihrer CSR nutzen wir den folgenden Befehl:

openssl req -noout -text -in com.cuegee.csr.pem

Einholen des Zertifikats bei einer Zertifizierungsstelle

Die zuvor erstellte Zertifikatsanforderung (CSR) müssen wir nun bei unserer Zertifizierungsstelle einreichen. Sobald diese das Zertifikat erstellt und signiert hat, können wir es dort herunterladen und fortfahren.

Verwenden des neuen Zertifikats in unserem AWS EKS Kubernetes Cluster

Schritt 1: Hochladen des Zertifikats in den AWS Secrets Manager

Um die Inhalte der tls.crt und tls.key-Dateien in einen JSON-String zu packen und zu AWS Secrets Manager hochzuladen, nutzen wir die folgenden Befehle:

TLS_CRT_CONTENT=$(<com.cuegee.crt.pem <IntermediateCA.crt)
TLS_KEY_CONTENT=$(<com.cuegee.key.pem)

SECRET_STRING=$(jq -n \
  --arg tlsCrt "$TLS_CRT_CONTENT" \
  --arg tlsKey "$TLS_KEY_CONTENT" \
  '{ "tls.crt": $tlsCrt, "tls.key": $tlsKey }')

aws secretsmanager put-secret-value \
  --secret-id MyTestSecret \
  --secret-string "$SECRET_STRING"

Schritt 2: Import des neuen Zertifikats in unser Kubernetes Cluster

Nach dem Hochladen in den AWS Secrets Manager importieren wir das Zertifikat in unser Kubernetes-Cluster. Hierfür nutzen wir den External Secrets Operator. Das importierte Secret können wir dann im Ingress nutzen:

---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: cuegee.com-tls
spec:
  secretStoreRef:
    kind: ClusterSecretStore
    name: secretsmanager
  target:
    name: cuegee.com-tls
    template:
      type: kubernetes.io/tls
  dataFrom:
    - extract:
        key: "tls-com.cuegee._"

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/server-snippet: |-
      add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains; preload'; # 💚 for HSTS
  labels:
  name: website-cuegee
spec:
  ingressClassName: nginx
  rules: {} # Removed for brevity
  tls:
    - hosts:
        - "*.cuegee.com"
      secretName: cuegee.com-tls

Durch diese Migration zu ECDSA verbessern wir nicht nur die Sicherheit, sondern auch die Leistung unserer Webserverzertifikate.

Wir hoffen, dass dieser Leitfaden hilft, ähnliche Schritte Projekten durchzuführen. Wenn es Fragen gibt oder Unterstützung benötigt wird, zögere nicht, uns zu kontaktieren.