We have configured Auth0 as Identity Provider for iPipeline.com in a TEST environment. However, we were told the following is a requirement for PRODUCTION:
The certificate used in PROD needs to be an official certificate issued by an authorized certificate authority
authorized certificate authority?To answer your question directly, Auth0 is not a certificate authority, however that should not be an issue. The certificates used for TLS (HTTPS) and which are associated with the tenant [tenant].auth0.com you created are indeed signed by a certificate authority as they need to be transparently trusted by any end-user browser/device that interacts with your account.
However, for the purpose of signing assertions/tokens that prove the identity of a given end-user account managed through Auth0 the certificate used, when applicable, is a self-signed one and not one issued by a certificate authority. However, this should not be an issue, because the trust relationship between the issuer of the assertions/tokens (Auth0) and the consumer (iPipeline) is configured manually.
In particular, you’re explicitly configuring iPipeline to trust the identity of users coming from that specific Auth0 certificate that you obtained and manually provided to iPipeline, this trust happens to be based on a certificate, but having that certificate being issued by a certificate authority would not add anything to the table in terms of trust relationship.
In conclusion, that requirement when applied to the certificates used for assertion/token signing should not be strictly required. Did you get that requirement from publicly available documentation or directly from iPipeline staff? The reason I ask is to try to understand the reason for that requirement as it may be for something else unrelated to the general trust relationship required in a federated authentication protocol. For example, they may want that for maintenance reasons in order to try to simplify the process in case the certificate needs to be rotated. As an additional note, the current self-signed certificate is long-lived so purely from a lifetime perspective there should be no need to frequent certificate changes.
I shared your response with the iPipeline support staff. Here’s what they shared:
The answer you got from that post is correct when saying “It may be for something else unrelated to the general trust relationship required in a federated authentication protocol.” It does not affect the actual protocol itself, however, it is a requirement enforced by our Production team for added security purposes.
How do you recommend we proceed from here?
To be honest I don’t see much options, as mentioned before the requirement is not that common and is usually just an optional thing that I don’t believe we support as to my knowledge we only offer the self-signed certificate option. If iPipeline has that hard requirement then this may be a blocker, I’ll try to inquire about this internally, but I honestly unsure if this will be feasible.