5
PFX Zertifikate und komisches Verhalten
Aloa in die Runde,
über folgenden 2 Zeilen drücken wir Zertifikate in spezielle Clients:
Jetzt haben wir die Zertifikate aktualisiert bekommen und wollten diese einspielen.
Zertifikate und passende Kennwörter bekannt. Genauso konfiguriert wie bei den Zertifikaten aus dem letzten Jahr.
Manuell einspielen läuft.
Ergebnis:
Ist ein Adminuser angemeldet werden die beiden obrigen Zeilen sauber automatisiert ausgeführt und alles dort im Store hinterlegt wo es hingehört.
Ist ein "Normalouser" angemeldet und wird das Script ausgeführt schlägt es fehl, obwohl das passende Kennwort zum PFX genutzt wird.
Mit den Zertifikaten vom letzten Jahr läuft es.
Umgebung: Win10 (x64) Enterprise LTSB
Mir erschließt sich nicht wo es da klemmt. Hat einer eine Idee was ich noch testen kann?
VG
über folgenden 2 Zeilen drücken wir Zertifikate in spezielle Clients:
$SecurePassword = ConvertTo-SecureString $PWD -AsPlainText -Force
Get-ChildItem -Path $Path | Import-PfxCertificate -CertStoreLocation Cert:\CurrentUser\My -Password $SecurePasswordJetzt haben wir die Zertifikate aktualisiert bekommen und wollten diese einspielen.
Zertifikate und passende Kennwörter bekannt. Genauso konfiguriert wie bei den Zertifikaten aus dem letzten Jahr.
Manuell einspielen läuft.
Ergebnis:
Ist ein Adminuser angemeldet werden die beiden obrigen Zeilen sauber automatisiert ausgeführt und alles dort im Store hinterlegt wo es hingehört.
Ist ein "Normalouser" angemeldet und wird das Script ausgeführt schlägt es fehl, obwohl das passende Kennwort zum PFX genutzt wird.
Mit den Zertifikaten vom letzten Jahr läuft es.
Umgebung: Win10 (x64) Enterprise LTSB
Mir erschließt sich nicht wo es da klemmt. Hat einer eine Idee was ich noch testen kann?
VG
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 440004
Url: https://administrator.de/contentid/440004
Ausgedruckt am: 04.12.2024 um 08:12 Uhr
5 Kommentare
Neuester Kommentar
Moin,
Gruß,
Dani
Ist ein "Normalouser" angemeldet und wird das Script ausgeführt schlägt es fehl, obwohl das passende Kennwort zum PFX genutzt wird.
Wie lautet die Fehlermeldung? Hast du die PFX-Datei selbst erstellt oder vom Aussteller erhalten? Umgebung: Win10 (x64) Enterprise LTSB
Welche Version?Gruß,
Dani
Aloa,
die Meldung die wir im Log haben lautet nur "Das Zertifikat konnte nicht importiert werden.".
Also mal wieder schön nichts sagend.
Die Zertifikate erstellen wir nicht selber, sondern bekommen diese geliefert.
Würden die sich manuell nicht importieren lassen könnte ich ja die Fehlermeldung noch verstehen.
Der Witz ist aber das es nur bei einem Nutzer mit Adminrechten automatisiert funktioniert.
;(
OS Version: Windows 10 Enterprise 2016 LTSB (Version: 1607; Build: 14393.2879)
die Meldung die wir im Log haben lautet nur "Das Zertifikat konnte nicht importiert werden.".
Also mal wieder schön nichts sagend.
Die Zertifikate erstellen wir nicht selber, sondern bekommen diese geliefert.
Würden die sich manuell nicht importieren lassen könnte ich ja die Fehlermeldung noch verstehen.
Der Witz ist aber das es nur bei einem Nutzer mit Adminrechten automatisiert funktioniert.
;(
OS Version: Windows 10 Enterprise 2016 LTSB (Version: 1607; Build: 14393.2879)
Moin,
Gruß,
Dani
Die Zertifikate erstellen wir nicht selber, sondern bekommen diese geliefert.
- könnte es sein, dass evtl. in der alten PFX-Datei kein Zertifikat für die vertrauenswürdige Stammzertifizierungsstelle dabei war?
- Wurde evtl. das neue Zertifikat mit 4096 Bits ausgestellt, so dass ein Bug von Windows 10 die Ursache ist? Könntest du mit einem Windows 10 Enterprise 2019 LTSB gegenprüfen.
- Das Skript mit Process Monitor beobachten, ob dort Auffälligkeiten zu sehen sind.
Gruß,
Dani
Hi Dani,
Alt:
- war noch ein Zwischenzertifizierungsstellen Zertifikat enthalten
- RSA (2048)
Das zu importierende Zertifikat hatte dann dieses über sich im Zertifizierungspfad, da dort nichts weiter drüber ist ist das dann das Stammzertifikat? obwohl es unter Zwischenzertifizierungsstellen einsortiert ist?
- RSA (2048)
Neu: (nach manuellem Import)
- enthält ein neues Zwischenzertifikat
- RSA (2048)
Das importierte ist genauso wie das vor einem Jahr in der Zertifizierungskette zu sehen.
4096Bits hat keines der Zertifikate die mir vorliegen.
Test auf einer 2019er LTSB ist mir hier in der Umgebung leider nicht möglich.
Einzig das Patchlevel ließe sich ggf. händisch auf das Niveau bringen von vor einem Jahr.
Wobei auch das "alte" Script auf dem aktuellen Patchlevel einwandfrei läuft.
Das Script selber ist leider eingebettet in ein Paket der Softwareverteillösung.
Es triggert im Grunde ein Powershellscript mit der Logik und den 2 Zeilen oben.
Da sich die Zertifikate mit Admin Users importieren lassen, stimmen die Kennwörter.
Ich werd den Process Monitor mal anwerfen, wüsste aber nicht wonach ich da direkt ausschau halten sollte.
Eine Idee war noch vielleicht schießt irgend eine GPO quer, die im "normalo" Kontext angezogen wird, aber das dürfte ja die alten Zertifikate auch nicht angezogen werden, da die Paketlogik die selbe ist, nur halt mit den alten Zertifikaten + Kennwörtern.
*argh*
VG
Alt:
- war noch ein Zwischenzertifizierungsstellen Zertifikat enthalten
- RSA (2048)
Das zu importierende Zertifikat hatte dann dieses über sich im Zertifizierungspfad, da dort nichts weiter drüber ist ist das dann das Stammzertifikat? obwohl es unter Zwischenzertifizierungsstellen einsortiert ist?
- RSA (2048)
<Zwischenstelle>
<Zertifikat>Neu: (nach manuellem Import)
- enthält ein neues Zwischenzertifikat
- RSA (2048)
Das importierte ist genauso wie das vor einem Jahr in der Zertifizierungskette zu sehen.
4096Bits hat keines der Zertifikate die mir vorliegen.
Test auf einer 2019er LTSB ist mir hier in der Umgebung leider nicht möglich.
Einzig das Patchlevel ließe sich ggf. händisch auf das Niveau bringen von vor einem Jahr.
Wobei auch das "alte" Script auf dem aktuellen Patchlevel einwandfrei läuft.
Das Script selber ist leider eingebettet in ein Paket der Softwareverteillösung.
Es triggert im Grunde ein Powershellscript mit der Logik und den 2 Zeilen oben.
Da sich die Zertifikate mit Admin Users importieren lassen, stimmen die Kennwörter.
Ich werd den Process Monitor mal anwerfen, wüsste aber nicht wonach ich da direkt ausschau halten sollte.
Eine Idee war noch vielleicht schießt irgend eine GPO quer, die im "normalo" Kontext angezogen wird, aber das dürfte ja die alten Zertifikate auch nicht angezogen werden, da die Paketlogik die selbe ist, nur halt mit den alten Zertifikaten + Kennwörtern.
*argh*
VG
*ARGH*
Wenn der Normalo User nicht lesend in das Verzeichnis darf dann wird das auch nix mit dem lesen vom Zertifikat.
;(
Wenn der Normalo User nicht lesend in das Verzeichnis darf dann wird das auch nix mit dem lesen vom Zertifikat.
;(
