Dieser Artikel wurde automatisch übersetzt. Die Übersetzung kann Ungenauigkeiten enthalten.
Zur englischen Originalversion wechseln.
Ctrlk
linkedinx-twitter
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Linux-Server

Diese Funktion erfordert Version 2.3.689 oder höher.

Nur SCEPman Enterprise Edition

Während die anderen Anwendungsfälle von SCEPman die Möglichkeit bieten, einen Benutzer interaktiv zu authentifizieren, um ihm dann nur zu erlauben, Benutzerzertifikate für sein Konto oder seine Geräte zu registrieren, möchten Sie vielleicht Zertifikate für beliebige Subjects nicht interaktiv registrieren können.

Um dies zu erreichen, können wir einen Service Principal authentifizieren und ihm erlauben, die Enrollment-REST-API von SCEPman zu nutzen.

Voraussetzungen

Bitte lesen Sie den Artikel zur API-Enrollment, um zu erfahren, wie ein Service Principal erstellt wird, der zur Authentifizierung verwendet werden kann:

API-Registrierung

PowerShell-Modul SCEPmanClient

Erste Anfragen

Sie können das PowerShell-Modul SCEPmanClient verwenden, um Zertifikate auf Ihrem Linux-Server anzufordern:

$Parameters = @{
    'Url'              = 'scepman.contoso.com'
    'ClientId'         = '569fbf51-aa63-4b5c-8b26-ebbcfcde2715'
    'TenantId'         = '8aa3123d-e76c-42e2-ba3c-190cabbec531'
    'ClientSecret'     = 'csa8Q~aVaWCLZTzswIBGvhxUiEvhptuqEyJugb70'
    'Subject'          = 'CN=LinuxServer'
    'IP'               = '10.22.11.8'
    'ExtendedKeyUsage' = 'ServerAuth'
    'SaveToFolder'     = '/etc/ssl/scepman'
    'IncludeRootCA'    = $true
}

New-SCEPmanCertificate @Parameters

Zertifikatserneuerung

Sie können das PowerShell-Modul auch verwenden, um bereits vorhandene Zertifikate zu erneuern. Dadurch entfällt außerdem die Notwendigkeit, für die Authentifizierung einen Dienstprinzipal zu verwenden:

Registrierungs- und Erneuerungsskript

Wenn das PowerShell-Modul für Sie keine Option ist, kann das enrollrenewcertificate.sh Skript verwendet werden, um zunächst ein Zertifikat zu beziehen sowie es zu überprüfen und im Falle eines baldigen Ablaufs eine Erneuerung zu versuchen.

Client-Voraussetzungen

Die folgenden Voraussetzungen müssen auf dem ausführenden Client/Host vorhanden sein, um die Enrollment REST API verwenden zu können.

Azure CLI (Version 2.61 und höher)

Die Azure CLI wird verwendet, um den authentifizierenden Benutzer zu verifizieren, seine Berechtigung zu prüfen und das Zugriffstoken abzurufen.

cURL

Wird verwendet, um das erstellte CSR an den SCEPman Enrollment API-Endpunkt zu senden und das Zertifikat zu empfangen.

OpenSSL

OpenSSL wird verwendet, um einen privaten Schlüssel zu erzeugen und ein CSR für die Ausstellung oder Erneuerung eines Zertifikats zu erstellen.

Beispiel:

1. Befehl

Definiert das Verhalten des Skripts

Für diesen Anwendungsfall können wir die folgenden Optionen verwenden:

-s für Serverzertifikate mit automatischer Erkennung, ob es sich um eine Erstregistrierung oder Verlängerung handelt

-y für die Erstregistrierung eines Serverzertifikats

-c zum Einreichen eines vorhandenen Certificate Signing Request

Zu Anwendungsfällen der Client-Authentifizierung siehe:

Nicht verwalteter Linux-Client

2. App Service-URL

Die URL des SCEPman-App-Services.

Beispiel: "https://scepman.contoso.net/"

3. API-Scope

Dies ist die Application ID URI des SCEPman-api App-Registrierung in Ihrer Umgebung erstellen können.

Beispiel: "api://a7a1d6c8-51b9-48ec-9ca0-a363dc2c8436"

4. Zertifikats-Dateiname

Der Dateiname (ohne Erweiterung) des Zertifikats, das erstellt oder zur Erneuerung gelesen wird.

Beispiel: "myCertificate"

5. Zertifikatsverzeichnis

Das Verzeichnis, in dem das Zertifikat erstellt oder dessen Erneuerung versucht wird.

Beispiel: ~/certs/

8. Verlängerungsschwelle

Die Anzahl der Tage, die das Zertifikat noch gültig sein muss, damit das Skript den Erneuerungsprozess startet.

Beispiel: 30

Zusätzliche Parameter für Serverzertifikate:

9. Service Principal Client-ID

Die Anwendungs-(Client)-ID der App-Registrierung, die wir authentifizieren möchten.

10. Service Principal Client-Geheimnis

Das erstellte Client-Geheimnis der App-Registrierung, die wir authentifizieren möchten.

11. Service Principal Tenant-ID

Die Tenant-ID unserer App-Registrierung.

12. Certificate Subject

Das Subject, mit dem Sie das Zertifikat registrieren möchten.

Format: /CN=SubjectName,O=Organization

13. Zertifikatserweiterung

Dies wird als Subject Alternative Name hinzugefügt

Beispiel: DNS:webserver.contoso.com

Verwendungsbeispiel für CSR-Signierung (Befehl -c)

Hinweise

  • Dieses Skript verschlüsselt die erzeugten Schlüssel nicht (dafür ist eine Passphrase-Eingabe erforderlich, daher wurde auf Verschlüsselung verzichtet, um eine automatische Erneuerung zu ermöglichen.)

  • Wenn Sie passphrasegeschützte Zertifikate aus Certificate Master erneuern, müssen Sie diese Passphrase eingeben, um sie zu erneuern.

Automatische Erneuerung einrichten

Wenn das obige Bash-Skript ausgeführt wird und erkennt, dass ein Zertifikat bereits registriert wurde, wird es das Zertifikat (falls es kurz vor dem Ablauf steht) mithilfe von mTLS erneuern. Wenn das Skript regelmäßig ausgeführt wird, wird dadurch sichergestellt, dass das Zertifikat erneuert wird, wenn es sich dem Ablauf nähert. Sie können dazu einen Cronjob einrichten. Der folgende Befehl ist ein Beispiel dafür, wie dies erledigt werden könnte. Er richtet einen Cronjob ein, der den Befehl täglich ausführt (wenn das System eingeschaltet ist), und einen Cronjob, der den Befehl beim Neustart ausführt.

Da Befehle, die von Cron ausgeführt werden, nicht unbedingt aus dem Verzeichnis ausgeführt werden, in dem sich das Skript/die Zertifikate befinden, ist es wichtig, die absoluten Pfade zum Skript/zu den Zertifikaten anzugeben.

Zuletzt aktualisiert

War das hilfreich?