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.