Search

Conflicts can occur in B2C Service when multiple Microsoft Entry ID certificates without Authority Key Identifier (AKID) extensions are present, as OpenSSL cannot distinguish between certificates with identical subject and issuer fields. This leads to unpredictable authentication failures in SSO setups for both agents (BUI/.NET) and customer portals. Following the guidelines and configuration changes suggested in this Pro Tip can help administrators ensure smooth SSO operation and avoid authentication issues caused by certificate conflicts.

Key points and solutions:

• Why Conflicts Occur:

  • Certificates lacking the AKID extension and sharing the same subject issuer cannot be reliably distinguished by OpenSSL, especially if multiple are needed (e.g., for both BUI/.NET and Customer Portal).

  • File read order affects which console (BUI/.NET vs. Customer Portal) may fail during certificate validation.

• Best Practice Solution:

  • Use certificates that include the Authority Key Identifier extension or ensure different subject issuer values for each certificate.

• Workarounds for Existing Certificates:

  • For agent SSO (BUI/.NET): Enable "Do Not Verify Trust Chain for Certificates" within the single sign-on configuration’s .NET component.

  • For customer portal SSO: Use "cert validation ignore trust" along with the required certificate fingerprints.

• Security Considerations:

  • Disabling chain trust validation for self-signed certificates is generally safe since signature and integrity checks are still performed.

  • Only disable trust chain validation for self-signed certificates when necessary and not for certificates issued by public CAs.

• Limitations and Recommendations:

  • Avoid using the same Microsoft Entry ID certificate for both agent and contact SSO on the same site if AKID is missing.

  • Consult the Oracle knowledge base and documentation for detailed instructions specific to your deployment and for troubleshooting assistance.