Windows
Zertifikate über SCEP in Intune mit SCEPman auf Windows-Geräte bereitstellen.
Der folgende Artikel beschreibt die Bereitstellung von Geräte- und/oder Benutzerzertifikaten für Windows-Geräte. Die Bereitstellung des SCEPman-Root-Zertifikats ist obligatorisch. Anschließend können Sie zwischen der Bereitstellung nur des Geräte-, nur des Benutzerzertifikats oder sogar beider Zertifikatstypen wählen.
Root-Zertifikat
Die Grundlage für die Bereitstellung von SCEP-Zertifikaten ist, dem Root-Zertifikat von SCEPman zu vertrauen. Daher müssen Sie das CA-Root-Zertifikat herunterladen und als ein Vertrauenswürdiges Zertifikat Profil über Microsoft Intune bereitstellen:
Beachten Sie, dass Sie dieselbe Gruppe für die Zuweisung des Vertrauenswürdigen Zertifikats und des SCEP-Profils verwenden müssen. Andernfalls kann die Intune-Bereitstellung fehlschlagen.
Gerätezertifikate
Format des Subject-Namens: 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 Subject-Namens, um das Gerät zu identifizieren, und als Seed 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 SCEPman 2.0 oder höher und 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-Geräte-ID ((URI)Wert: IntuneDeviceId://{{DeviceId}}) bereitgestellt im Subject Alternative Name (SAN).
Wichtig: Die Wahl des CN-Feldes beeinflusst das automatische Widerrufsverhalten von Zertifikaten, die für Ihre von Intune verwalteten Geräte ausgestellt wurden.
Sie können bei Bedarf weitere RDNs hinzufügen (z. B.: CN={{DeviceId}}, O=Contoso, CN={{WiFiMacAddress}}). Unterstützte Variablen sind in den Microsoft-Dokumenten.
Subject Alternative Name: (URI)Wert: IntuneDeviceId://{{DeviceId}}
Das URI-Feld wird von Microsoft empfohlen um NAC-Lösungen zu ermöglichen, die Geräte anhand ihrer Intune-Geräte-ID zu identifizieren. Der Wert sollte sein:
Das URI-Feld ist obligatorisch falls weder CN={{DeviceId}} noch CN={{AAD_Device_ID}} im Subject name format Feld verwendet wird.
Weitere 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. Standardmäßig ist ein Jahr festgelegt.
SCEPman begrenzt die Zertifikatsgültigkeit auf das konfigurierte Maximum in der Einstellung AppConfig:ValidityPeriodDays, verwendet andernfalls aber die in der Anforderung konfigurierte Gültigkeit.
Key Storage Provider (KSP): Bei Trusted Platform Module (TPM) KSP anmelden, andernfalls fehlschlagen
Diese Einstellung bestimmt den Speicherort des privaten Schlüssels für die Endbenutzerzertifikate. Die Speicherung im TPM ist sicherer als die Software-Speicherung, da das TPM eine zusätzliche Sicherheitsebene bietet, um den Diebstahl von Schlüsseln zu verhindern.
Hinweis: Es gibt einen Fehler in einigen älteren TPM-Firmware-Versionen , der einige Signaturen ungültig macht, die mit einem TPM-gebundenen privaten Schlüssel erstellt wurden. In solchen Fällen kann das Zertifikat nicht für die EAP-Authentifizierung verwendet werden, wie sie für WLAN- 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 Key Storage Provider aus.
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 in dem Artikel von Richard Hicks und Microsoft Q&A
Key usage: Digitale Signatur und Schlüsselaustausch
Bitte aktivieren Sie beide kryptografischen Aktionen.
SCEPman setzt Key usage automatisch auf Digitale Signatur und Schlüsselaustausch und überschreibt die Einstellung hier, sofern die Einstellung AppConfig:UseRequestedKeyUsages nicht auf true.
Root-Zertifikat: Profil aus dem vorherigen Schritt (Profil für Root-Zertifikat)
Bitte wählen Sie das Intune-Profil aus #Root Certificate. Wenn Sie eine Zwischen-CAverwenden, müssen Sie das Vertrauenswürdige-Zertifikat-Profil für die Zwischen-CA auswählen, nicht die Root-CA!
Extended key use: 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 Werte. Die anderen Felder werden automatisch ausgefüllt.
Erneuerungsschwelle (%): 20
Dieser Wert definiert, wann das Gerät sein Zertifikat erneuern darf (basierend auf der verbleibenden Lebensdauer eines vorhandenen Zertifikats). Bitte lesen Sie den Hinweis unter Gültigkeitsdauer des Zertifikats und wählen Sie einen geeigneten Wert, der dem Gerät erlaubt, das Zertifikat über einen längeren Zeitraum zu erneuern. Ein Wert von 20 % würde dem Gerät mit einem 1 Jahr gültigen Zertifikat erlauben, 73 Tage vor Ablauf mit der Erneuerung zu beginnen.
SCEP-Server-URLs: Öffnen Sie das SCEPman-Portal und kopieren Sie die URL von Intune MDM
Beispiel
Beispiel
Benutzerzertifikate
Bitte befolgen Sie die Anweisungen unter #Device certificates und beachten Sie die folgenden Unterschiede:
Format des Subject-Namens: CN={{UserName}},E={{EmailAddress}}
Sie können RDNs nach Ihren Bedürfnissen definieren. Unterstützte Variablen sind in den Microsoft-Dokumenten. Wir empfehlen, den Benutzernamen (z. B. janedoe) und die E-Mail-Adresse (z. B. [email protected]) als Grundeinstellung aufzunehmen.
Subject Alternative Name: (UPN)Wert: {{UserPrincipalName}}
Sie müssen den Benutzerprinzipalnamen als Subject Alternative Name hinzufügen. Fügen Sie '{{UserPrincipalName}}' als Subject Alternative Name vom Typ Benutzerprinzipalname (UPN) hinzu. Dadurch wird sichergestellt, dass SCEPman Zertifikate Benutzerobjekten in AAD zuordnen kann. Die Einstellung für 'Subject name format' ist frei wählbar.
Weitere SAN-Werte wie eine E-Mail-Adresse können bei Bedarf hinzugefügt werden.
Auf Grundlage von Kundenfeedback scheint es, dass einige VPN-Clients (z. B. Azure VPN Client für Virtual WAN) das Benutzerzertifikat nicht finden können, wenn es im TPM gespeichert ist. Versuchen Sie stattdessen, es beim Software-KSP anzumelden.
Beispiel
Benutzerzertifikat für digitale Signatur
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 eine separate Technologie für die Schlüsselverwaltung). Die Natur des SCEP-Protokolls enthält keinen Mechanismus zum Sichern oder Archivieren von privatem Schlüsselmaterial. Wenn Sie SCEP für die E-Mail-Verschlüsselung verwenden würden, könnten Sie später die Schlüssel zum Entschlüsseln der Nachrichten verlieren.
AppConfig:UseRequestedKeyUsagesgesetzt auftrueAppConfig:ValidityPeriodDaysgesetzt auf365(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) Benutzerprinzipalname (UPN):
{{UserPrincipalName}}(erforderlich) E-Mail-Adresse:
{{EmailAddress}}
Bei der Bereitstellung eines Zertifikats für digitale Signaturen müssen Sie den UPN und die E-Mail-Adresse hinzufügen.
Extended key usage: 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 Werte. Die anderen Felder werden automatisch ausgefüllt.
Erneuerungsschwelle (%): 50
Wir empfehlen, die Erneuerungsschwelle (%) auf einen Wert zu setzen, der sicherstellt, dass Zertifikate bei der Ausstellung von S/MIME-Signaturzertifikaten mindestens 6 Monate vor Ablauf erneuert werden. Dies liegt daran, dass E-Mails, die mit abgelaufenen Zertifikaten signiert wurden, in Outlook als Signaturen mit ungültiger Signatur angezeigt werden, was Benutzer verwirrt. Ein neues Zertifikat lange bevor das alte abläuft sorgt dafür, dass nur ältere E-Mails dieses Verhalten zeigen, die sich Benutzer wahrscheinlich seltener 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 unter Vorgesehene Verwendungszwecke sehen Secure Email
Das Zertifikat steht dann für die Verwendung als digitale Signatur 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 Classic Outlook kann eingerichtet werden manuell oder schnell eingerichtet mit unserem PowerShell-Skript.
Outlook im Web
S/MIME für Outlook im Web kann eingerichtet werden manuell oder mit PowerShell mit folgendem Befehl aktiviert werden:
Zusätzliche PowerShell-Befehle können hier.
Zuletzt aktualisiert
War das hilfreich?