Azure B2C – Benutzerdefinierte Richtlinien – Ersetzen des Let’s Encrypt-Zertifikats durch ein Comodo/Sectigo-Zertifikat nicht zulässig

Azure B2C – Benutzerdefinierte Richtlinien – Ersetzen des Let’s Encrypt-Zertifikats durch ein Comodo/Sectigo-Zertifikat nicht zulässig

Ich habe einen Azure B2C-Mandanten, der benutzerdefinierte Richtlinien verwendet, um eine Verbindung zu unserer eigenen API herzustellen. Die Richtlinie wird derzeit mit einem *.something.dev-Zertifikat bereitgestellt und läuft alle 3 Monate ab. Der Plan besteht darin, dieses aktuelle Zertifikat durch ein von einer Zertifizierungsstelle ausgestelltes Zertifikat zu ersetzen, sodass wir das Zertifikat nicht viermal im Jahr, sondern nur einmal ersetzen müssen.

Der Fehler, den wir nach dem Hochladen eines Comodo CA-Zertifikats erhalten, lautet jedoch Microsoft.Cpim.Common.PolicyException:

Gibt es irgendwo in Azure eine CA oder Einschränkungen, die diese Probleme verursachen könnten? Ich kann mich nicht erinnern, in Azure irgendwelche CA-bezogenen Einstellungen vorgenommen zu haben.

Wenn wir die Comodo CA durch ein Let’s Encrypt-Zertifikat ersetzen, funktioniert der Dienst wieder. Der Code auf unserer Seite lässt den Fingerabdruck beider Zertifikate zu, das verursacht also nicht das Problem.

Ich habe bisher versucht:

  • Ersetzen unserer URL im Webdienst (verschoben von „something.test.dev“ nach „someotherdomain.com“).
  • 2048 Zertifikate durch 4096 ersetzt und umgekehrt.
  • Neue Richtlinien erstellt (B2C_1A_EnrichmentApiClientCertificate)
  • Habe einen neuen B2C-Mandanten erstellt und alle Einstellungen noch einmal vorgenommen.
  • Wenn ich unsere eigene API offline schalte, erhalte ich diesen Fehler: Microsoft.Cpim.Common.Web.ConnectionExceptionIch bin also 100 % sicher, dass wir genau diese API aufrufen.
  • Alle CAA-Einträge entfernt, um zu sehen, ob diese damit in Zusammenhang stehen

Antwort1

Die Antwort auf diese Frage liegt in der Zertifikatskette.

Die Kette war falsch konfiguriert und wir hatten Nicht-Root-Zertifikate im Root-Speicher auf dem Server abgelegt, was zu Problemen führte.

Das Entfernen der falschen Zertifikate hat dieses Problem für uns behoben.

Wie haben wir das gelöst:

  • Vergleichen Sie die mmc.exe eines funktionierenden Computers/Servers mit einer nicht funktionierenden Umgebung und entfernen Sie die Zertifikate, die nicht übereinstimmen.

verwandte Informationen