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:

https://dev.apis.example.com/v1/addressValidation/validateAddress

instead of the default
https://gav-3scale-apicast-staging.apps.example-test.x4z39.p1.openshiftapps.com/v1/addressValidation/validateAddress.
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.

Implementation

• 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

Questions

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

https://github.com/3scale/porta/blob/16e9f6eb97fff2b63a58f3d9bca7d3195f550581/app/services/proxy_test_service.rb#L110

So we may need also to add certificates customization in the onboarding