This is only for API routes.
Please read the description of the epic that corresponds to this issue.
The ability for a customer to use their own custom (vanity) domain name (e.g. dev.apis.example.com) and corresponding certificate to configure a more friendly and "trustable" (i.e. looks like it originates from our client) URL for APIs hosted by 3Scale for example:
instead of the default
has been removed.
To support this custom certificate, a customer will be able to add a CNAME record in their DNS to point this end point.
Please read this comment
This was a feature when supported in OSD 3, but removed in versions that support OSD 4 and zync hence the regression. This customer branding of such exposed services is still expected in any managed or SaaS offering in the industry today.
- One table storing the certificates, those would probably needs to be encrypted values … security concerns.
- zync being able to fetch the certificates from system API (private key and CA) and upload it to openshift on routes creation/update
- Need to be able to test the API routes with the CA file in case of self-signed certificate
Encryption/Re-encryption: Do we need to store encrypted values of the certificates? It would be adding too much work to handle: rotation, re-encryption etc ... Also System-Zync networking is done through internal Openshift network or on HTTPS. <- amasferr
Testing API routes against the CA is needed, there is a API Proxy test done on onboarding
So we may need also to add certificates customization in the onboarding