Öffentliches Zertifikat erneuern: Fehler beim Generieren eines CSR File (.req)

[andrew 15]

Hallo zusammen

 

Ziel

Ein öffentliches Zertifikat vom Anbieter RapidSSL erneuern.

 

Was ist noch zu erledigen?

RapidSSL: Einloggen und CSR (Certificate Signing Request) einreichen

 

Was habe ich versucht?

1. Via Exchange URL https://ExchangeServer.domain.ch/ecp unter dem Punkt Server/ Zertifikate das *.domain.ch Zertifikat angeklickt und via Knopf "erneuern" versucht, das CSR (Text File) nach folgendem
Schema zu erzeugen: \\DateiServer\Share\RequestFile.req 

2. da hier ein Fehler generiert wurde (anbei aufgeführt), hatte ich noch via Exchange PS mein Glück versucht, auch da erhielt ich einen Fehler (weiter unten beschrieben)

 

Fehler via URL /ecp

Verwenden Sie einen gültigen Dateinamen, wenn Sie das Cmdlet "New-ExchangeCertificate" auf dem Server IVSO-XCH02 mit dem Parameter "RequestFile" ausführen. Die Datei darf nicht im Zielordner vorhanden sein. Parametername: Requestfile

 

Bemerkung dazu

1. ich bin als 0815 User an meiner Win10 Kiste eingeloggt

2. hatte die URL https://ExchangeServer.domain.ch/ecp augerufen

3. hatte mich mit meinem Domänen Administrator eingeloggt

4. und bin wie soeben beschrieben, vorgegangen.

5. Rufe ich den Share \\DateiServer\Share z.B. von einem Server aus, bin an diesem Server mit meinem besagten Domänen Administrator eingeloggt, so kann ich auch Ordner/ Dateien in diesem Share, wo ich mein .req File speicher möchte/ wollte, erstellen. Es dürfte also auch nicht an fehlenden Schreibrechten liegen.

6. in diesem Besagten Pfad, wo ich das .req File nun neu speichern möchte, liegt auch kein anderes .req File, so wie es die Fehlermeldung mir weiss machen will.

 

Fehler via Exchange PS

Nach folgendem Schema habe ich mir einen PS Befehl zusammengestellt und abgesetzt:

 

$txtrequest = Get-ExchangeCertificate -Thumbprint 0ABCXYZABCXYZABCYAZABC00778899usw. | New-ExchangeCertificate -GenerateRequest -KeySize 2048 -Server ExchangeServer.domain.local [System.IO.File]::WriteAllBytes('\\DateiServer\Share\Wildcard\WildCardCert.req', [System.Text.Encoding]::Unicode.GetBytes($txtrequest))

 

 

Ausnahme beim Aufrufen von "GetBytes" mit 1 Argument(en):  "Das Array darf nicht NULL sein.
Parametername: chars"
In Zeile:1 Zeichen:1
+ $txtrequest = Get-ExchangeCertificate -Thumbprint 00FE89FACABA5309766 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : ArgumentNullException

 

[tobinator_1991 1]

moin @andrew

melde dich doch via RDP auf dem Exchange an und erzeuge den CSR über die IIS

[NorbertFe 1.825]

vor 56 Minuten schrieb tobinator_1991:

melde dich doch via RDP auf dem Exchange an und erzeuge den CSR über die IIS

Wozu? einen CSR per Exchange Management Shell zu erzeugen ist ne Sache von 30 Sekunden. Wers bequem haben will:

https://www.digicert.com/easy-csr/exchange2010.htm

Das gilt weiterhin und funktioniert problemlos. Befehl zusammenklicken und in der Powershell ggf. noch mit einem passenden Pfad ausführen.

[andrew 15]

Ich konnte nun via Exchange Admin Center unter Punkt Server/ Zertifikate das besagte RapidSSL Zertifikat anklicken und via Buton "erneuern" und somit die .req Datei speichern, Aber: Nur wenn ich als UNC Pfad den eigenen Exchange Server verwendete. 

 

Der Speicherpfad zur .req Datei sah also in meinem Fall nun so aus: \\ExchangeServer\Share\Zertifikat.req

Warum die Angabe \\DateiServer\Share\Zertifikat.req NICHT funktioniert hatte, obwohl ich der Ansicht bin, dass der eingeloggte User im Exchange Admin Center Schreibrechte auf den Share hatte, entzieht sich meiner Kenntnis Und: Man muss ja im Leben nicht alles verstehen, Hauptsache, so klappt es.

 

Der Rest sollte nicht mehr eine grosse Herausforderung sein, danke trotzdem allen für die Unterstützung

bearbeitet 13. Juli 2022 von andrew

[NorbertFe 1.825]

vor 51 Minuten schrieb andrew:

dass der eingeloggte User im Exchange Admin Center Schreibrechte auf den Share hatte, entzieht sich meiner Kenntnis

Weil da der Exchange hinschreibt und nicht der User. So jetzt haste deine Kenntnis, warum das nicht funktionierte. ;)