Windows

Zertifikate mithilfe von SCEP in Intune auf Windows-Geräten mit SCEPman bereitstellen.

Der folgende Artikel beschreibt die Bereitstellung von Geräte- oder/und Benutzerzertifikaten für Windows-Geräte. Die Bereitstellung des SCEPman Root Certificate ist obligatorisch. Danach können Sie zwischen der Bereitstellung nur des Geräte-, nur des Benutzerzertifikats oder sogar beider Zertifikatstypen wählen.

Root Certificate

Die Grundlage für die Bereitstellung von SCEP-Zertifikaten ist das Vertrauen in das Root Certificate von SCEPman. Daher müssen Sie das CA-Root-Zertifikat herunterladen und es als Vertrauenswürdiges Zertifikat Profil über Microsoft Intune bereitstellen:

• Laden Sie das CA-Zertifikat aus dem SCEPman-Portal herunter:

• Erstellen Sie ein Profil für Windows 10 und höher vom Typ Vertrauenswürdiges Zertifikat in Microsoft Intune:

• Laden Sie Ihre zuvor heruntergeladene .cer-Datei.

• Nun können Sie dieses Profil auf Ihre Geräte bereitstellen. Bitte wählen Sie Alle Benutzer und/oder Alle Geräte oder eine dedizierte Gruppe für die Zuweisung aus.

Beachten Sie, dass Sie für die Zuweisung des Vertrauenswürdigen Zertifikats und des SCEP-Profils dieselbe Gruppe verwenden müssen. Andernfalls kann die Intune-Bereitstellung fehlschlagen.

Gerätezertifikate

• Öffnen Sie das SCEPman-Portal und kopieren Sie die URL unter Intune MDM

• Erstellen Sie ein Profil für Windows 10 und höher vom Typ SCEP-Zertifikat in Microsoft Intune

• Konfigurieren Sie das Profil wie beschrieben:

Zertifikattyp: Gerät

In diesem Fall richten wir ein Gerätezertifikat ein

Format des Betreffnamens: CN={{DeviceName}} oder CN={{DeviceId}} oder CN={{AAD_Device_ID}}

Empfohlen: Verwenden Sie {{DeviceName}}für das CN-RDN, um einen aussagekräftigen Namen des Zertifikats auf dem Gerät oder bei der Suche nach dem Zertifikat zu haben.

Optional: Wenn konfiguriert auf CN={{DeviceId}} oder CN={{AAD_Device_ID}}, verwendet SCEPman das CN-Feld des Betreffnamens, um das Gerät zu identifizieren, und als Ausgangswert für die Generierung der Zertifikats-Seriennummer. Microsoft Entra ID (Azure AD) und Intune bieten zwei verschiedene IDs an:

• {{DeviceId}}: Diese ID wird von Intune generiert und verwendet. (erfordert, AppConfig:IntuneValidation:DeviceDirectory auf Intune oder AADAndIntune)

• {{AAD_Device_ID}}: Diese ID wird von Microsoft Entra ID (Azure AD) generiert und verwendet.

Falls weder CN={{DeviceId}} noch CN={{AAD_Device_ID}} für das CN-Feld verwendet wird (z. B. CN={{DeviceName}}), identifiziert SCEPman das Gerät anhand der Intune Device ID ((URI)Wert: IntuneDeviceId://{{DeviceId}}) bereitgestellt im Subject Alternative Name (SAN).

Sie können diese Variablen und statischen Text im Textfeld angeben. Der Common Name für ein Gerät mit dem Namen Device1 kann beispielsweise wie folgt hinzugefügt werden: CN={{DeviceName}}YourDomain.com

Wichtig: Die Wahl des CN-Felds beeinflusst das automatische Sperrverhalten von Zertifikaten, die an Ihre von Intune verwalteten Geräte ausgestellt werden.

Bei Bedarf können weitere RDNs hinzugefügt werden (z. B.: CN={{DeviceId}}, O=Contoso, CN={{WiFiMacAddress}}). Unterstützte Variablen sind in den Microsoft docs.

Subject alternative name: (URI)Wert: IntuneDeviceId://{{DeviceId}}

Das URI-Feld wird von Microsoft empfohlen um NAC-Lösungen die Identifizierung der Geräte anhand ihrer Intune Device ID zu ermöglichen. Der Wert sollte lauten:

IntuneDeviceId://{{DeviceId}}

Das URI-Feld ist obligatorisch für den Fall, dass weder CN={{DeviceId}} noch CN={{AAD_Device_ID}} im Format des Betreffnamens Feld verwendet wird.

Andere SAN-Werte wie DNS können bei Bedarf hinzugefügt werden.

Gültigkeitsdauer des Zertifikats: 1 Jahr

Die verbleibende Zeit, bevor das Zertifikat abläuft. Standard ist ein Jahr.

SCEPman begrenzt die Zertifikatsgültigkeit auf das in der Einstellung konfigurierte Maximum AppConfig:ValidityPeriodDays, verwendet ansonsten jedoch die in der Anforderung konfigurierte Gültigkeit.

Schlüsselspeicheranbieter (KSP): Bei Trusted Platform Module (TPM) KSP registrieren, andernfalls fehlschlagen

Diese Einstellung bestimmt den Speicherort des privaten Schlüssels für die Benutzerendzertifikate. Die Speicherung im TPM ist sicherer als die Software-Speicherung, da das TPM eine zusätzliche Sicherheitsebene bietet, um Schlüsseldiebstahl zu verhindern.

Hinweis: Es gibt einen Fehler in einigen älteren TPM-Firmware-Versionen der einige Signaturen ungültig macht, die mit einem TPM-gestützten privaten Schlüssel erstellt wurden. In solchen Fällen kann das Zertifikat nicht für EAP-Authentifizierung verwendet werden, wie sie bei Wi-Fi- und VPN-Verbindungen üblich ist. Außerdem kann dies Ihren Autopilot-Onboarding-Prozess beeinträchtigen.

Betroffene TPM-Firmware-Versionen umfassen:

• STMicroelectronics: 71.12, 73.4.17568.4452, 71.12.17568.4100, 73.20.17568.6684

• Intel: 11.8.50.3399, 2.0.0.2060

• Infineon: 7.63.3353.0

• IFX: Version 3.19 / Spezifikation 1.2

• IFX Version 7.63.3353.0 Spezifikation 2.0

Wenn Sie TPM mit dieser Firmware verwenden, aktualisieren Sie entweder Ihre Firmware auf eine neuere Version oder wählen Sie "Software KSP" als Schlüsselspeicheranbieter.

Aktualisierung: Sie können den TPM-Fehler umgehen, indem Sie die RSA-PSS-Signaturalgorithmen - die das Problem verursachen - aus der Registrierung entfernen. Weitere Informationen finden Sie bei Richard Hicks' Artikel und Microsoft Q&A

Schlüsselverwendung: Digitale Signatur und Schlüsselverschlüsselung

Bitte aktivieren Sie beide kryptografischen Aktionen.

SCEPman setzt die Schlüsselverwendung automatisch auf Digitale Signatur und Schlüsselverschlüsselung und überschreibt die Einstellung hier, sofern die Einstellung AppConfig:UseRequestedKeyUsages auf true.

Schlüsselgröße (Bits): 2048

SCEPman unterstützt 2048 Bit.

Hash-Algorithmus: SHA-2

SCEPman unterstützt den SHA-2-Algorithmus.

Root Certificate: Profil aus dem vorherigen Schritt (Root certificate Profile)

Bitte wählen Sie das Intune-Profil aus #Root Certificate. Wenn Sie eine Intermediate CAverwenden, müssen Sie das Vertrauenswürdiges-Zertifikat-Profil für die Intermediate CA auswählen, nicht die Root CA!

Erweiterte Schlüsselverwendung: Client Authentication, 1.3.6.1.5.5.7.3.2

Bitte wählen Sie Client Authentication (1.3.6.1.5.5.7.3.2) unter Vordefinierte Werteaus. Die anderen Felder werden automatisch ausgefüllt.

Erneuerungsschwelle (%): 20

Dieser Wert definiert, wann das Gerät sein Zertifikat erneuern darf (basierend auf der verbleibenden Laufzeit eines vorhandenen Zertifikats). Bitte lesen Sie den Hinweis unter Gültigkeitsdauer des Zertifikats und wählen Sie einen geeigneten Wert, der dem Gerät ermöglicht, das Zertifikat über einen langen Zeitraum zu erneuern. Ein Wert von 20 % würde es dem Gerät mit einem 1 Jahr gültigen Zertifikat erlauben, die Erneuerung 73 Tage vor Ablauf zu starten.

SCEP Server-URLs: Öffnen Sie das SCEPman-Portal und kopieren Sie die URL von Intune MDM

Beispiel

https://scepman.contoso.com/certsrv/mscep/mscep.dll

Beispiel

• Nun können Sie dieses Profil auf Ihre Geräte bereitstellen. Bitte wählen Sie für die Zuweisung dieselbe(n) Gruppe(n) wie für das Vertrauenswürdige-Zertifikat-Profil aus.

Benutzerzertifikate

Bitte befolgen Sie die Anweisungen unter #Gerätezertifikate und beachten Sie die folgenden Unterschiede:

Zertifikattyp: Benutzer

In diesem Abschnitt richten wir ein Benutzerzertifikat ein.

Format des Betreffnamens: CN={{UserName}},E={{EmailAddress}}

Sie können RDNs nach Bedarf definieren. Unterstützte Variablen sind in den Microsoft docs. Wir empfehlen, den Benutzernamen (z. B.: janedoe) und die E-Mail-Adresse (z. B.: [e-mail]) als Grundeinstellung zu verwenden.

Subject alternative name: (UPN)Wert: {{UserPrincipalName}}

Sie müssen den User Principal Name als Subject Alternative Name hinzufügen. Fügen Sie '{{UserPrincipalName}}' als Subject Alternative Name vom Typ User principal name (UPN) hinzu. Dadurch wird sichergestellt, dass SCEPman Zertifikate mit Benutzerobjekten in AAD verknüpfen kann. Die Einstellung für 'Format des Betreffnamens' ist frei wählbar.

Andere SAN-Werte wie eine E-Mail-Adresse können bei Bedarf hinzugefügt werden.

Basierend auf Kundenfeedback scheint es, dass einige VPN-Clients (z. B. Azure VPN Client für Virtual WAN) nicht in der Lage sind, das Benutzerzertifikat zu erkennen, wenn es im TPM gespeichert ist. Versuchen Sie stattdessen, es dem Software-KSP zuzuweisen.

Beispiel

Benutzer-Digital-Signatur-Zertifikat

Sie können SCEPman für transnationale digitale Signaturen verwenden, d. h. für S/MIME-Signaturen in Microsoft Outlook. Wenn Sie die Zertifikate für die Nachrichtensignatur verwenden möchten, müssen Sie die entsprechenden erweiterten Schlüsselverwendungen in der Intune-Profilkonfiguration hinzufügen.

Verwenden Sie SCEPman nicht für E-Mail-Verschlüsselung d. h. für S/MIME-E-Mail-Verschlüsselung in Microsoft Outlook (ohne separate Technologie für die Schlüsselverwaltung). Die Natur des SCEP-Protokolls enthält keinen Mechanismus zum Sichern oder Archivieren privater Schlüsselmaterialien. Wenn Sie SCEP für E-Mail-Verschlüsselung verwenden würden, könnten Sie die Schlüssel zum späteren Entschlüsseln der Nachrichten verlieren.

• Sie müssen diese Konfigurationsvariablen festlegen, andernfalls werden die angeforderte Schlüsselverwendung und die erweiterte Gültigkeitsdauer im SCEP-Profil von SCEPman nicht berücksichtigt:

• AppConfig:UseRequestedKeyUsages festgelegt auf true

• AppConfig:ValidityPeriodDays festgelegt auf 365 (ein Maximalwert von 1825 - 5 Jahre ist möglich)

Um Benutzerzertifikate für Digitale Signaturen bereitzustellen, befolgen Sie bitte die Anweisungen unter #User certificates und beachten Sie die folgenden Unterschiede und Hinweise:

Subject alternative name

• (erforderlich) User principal name (UPN): {{UserPrincipalName}}

• (erforderlich) E-Mail-Adresse: {{EmailAddress}}

Durch die Bereitstellung eines Zertifikats für digitale Signaturen müssen Sie UPN und E-Mail-Adresse hinzufügen.

Schlüsselverwendung: nur Digitale Signatur

Erweiterte Schlüsselverwendung: Secure Email (1.3.6.1.5.5.7.3.4)

Bitte wählen Sie Secure Email (1.3.6.1.5.5.7.3.4) unter Vordefinierte Werteaus. Die anderen Felder werden automatisch ausgefüllt.

Erneuerungsschwelle (%): 50

Wir empfehlen, die Erneuerungsschwelle (%) so zu setzen, dass Zertifikate bei der Ausstellung von S/MIME-Signaturzertifikaten mindestens 6 Monate vor Ablauf erneuert werden. Der Grund dafür ist, dass E-Mails, die mit abgelaufenen Zertifikaten signiert wurden, in Outlook als ungültig signiert angezeigt werden, was Benutzer verwirrt. Wenn ein neues Zertifikat lange vor Ablauf des alten vorhanden ist, wird sichergestellt, dass nur ältere E-Mails dieses Verhalten zeigen, die Benutzer mit geringerer Wahrscheinlichkeit ansehen. Wenn Ihre Signaturzertifikate beispielsweise ein Jahr gültig sind, sollten Sie die Erneuerungsschwelle auf mindestens 50 % setzen.

Beispiel

Nach einer erfolgreichen Profilsynchronisierung sollten Sie das Benutzerzertifikat für Bestimmte Verwendungszwecke sehen Secure Email

Das Zertifikat steht für die Verwendung von Digital Signature z. B. in Outlook zur Verfügung. Unten sehen Sie ein Beispiel für die Verwendung

S/MIME-Signaturen in Outlook aktivieren

Sobald Sie S/MIME-Signaturzertifikate auf Ihren Client-Computern bereitgestellt haben, müssen Sie Outlook so konfigurieren, dass diese Zertifikate vor dem Senden signierter E-Mails verwendet werden.

Neues Outlook

S/MIME für das neue Outlook kann eingerichtet werden manuell.

Klassisches Outlook

S/MIME für das klassische Outlook kann eingerichtet werden manuell oder schnell eingerichtet werden mit unserem PowerShell-Skript.

Outlook im Web

S/MIME für Outlook im Web kann eingerichtet werden manuell oder mit PowerShell mit dem folgenden Befehl aktiviert werden:

Set-SmimeConfig -OWAAllowUserChoiceOfSigningCertificate $true

Zusätzliche PowerShell-Befehle können hier.