I did my research and found out that it can be done by creating an alias for the Virtual Host and that this operation can only be done through API calls.
First problem i found is that it cannot be done using the default port 80
curl -X POST -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/virtualhosts -d '<VirtualHost name="custom"><ClientCertForwarding>false</ClientCertForwarding><HostAliases><HostAlias>api.example.com</HostAlias></HostAliases><Interfaces/><ListenOptions/><Port>80</Port></VirtualHost>' -u orgAdminEmail:pWord
{
"code" : "messaging.config.beans.VirtualHostPortValidationError",
"message" : "Virtual host creation/update failed due to invalid port 80. Allowed port is 443. Contact support to allow custom port configuration",
"contexts" : [ ]
}
Then i tried using using port 443
curl -X POST -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/environments/{env_name}/virtualhosts -d '<VirtualHost name="custom"><ClientCertForwarding>false</ClientCertForwarding><HostAliases><HostAlias>api.example.com</HostAlias></HostAliases><Interfaces/><ListenOptions/><Port>443</Port><SSLInfo><Enabled>true</Enabled><ClientAuthEnabled>false</ClientAuthEnabled><KeyStore>ref://newref</KeyStore><KeyAlias>new</KeyAlias><ClientAuthEnabled>false</ClientAuthEnabled></SSLInfo></VirtualHost>' -u orgAdminEmail:pWord
{
"code" : "messaging.config.beans.VirtualHostCACertValidationError",
"message" : "Virtual host creation/update failed due to keystore cert validation error. Cert is invalid or cannot be not be trusted by java trust anchors or CAs",
"contexts" : [ ]
}
But the self signed certificates does not work.
I followed the instructions found here:
How can i safely buy a certificate if i cannot see the change working with the self signed certificate?
Solved! Go to Solution.
I have done this with certificates issued by a 3rd-party CA, specifically LetsEncrypt.
This is what we call "API white labeling."
It means mapping a DNS name like "api.mycompany.com" to "ORG-ENV.apigee.net" so that you can publish API endpoints that look like https://api.mycompany.com/foo/bar . Yes, only with TLS.
Until recently, it has been possible to white-label API endpoints only with the help of Apigee support. You'd have to open a ticket to ask for a secure vhost, and you'd have to securely transmit the cert and private key to support, wait for the ticket to be fulfilled... hours? days? But self-service vhosts have changed that. Now anyone can white label Apigee APIs, on any organization.
What's necessary? You need:
Steps:
For the record, we're looking into making this MUCH easier.
I have done this with certificates issued by a 3rd-party CA, specifically LetsEncrypt.
This is what we call "API white labeling."
It means mapping a DNS name like "api.mycompany.com" to "ORG-ENV.apigee.net" so that you can publish API endpoints that look like https://api.mycompany.com/foo/bar . Yes, only with TLS.
Until recently, it has been possible to white-label API endpoints only with the help of Apigee support. You'd have to open a ticket to ask for a secure vhost, and you'd have to securely transmit the cert and private key to support, wait for the ticket to be fulfilled... hours? days? But self-service vhosts have changed that. Now anyone can white label Apigee APIs, on any organization.
What's necessary? You need:
Steps:
For the record, we're looking into making this MUCH easier.
Hey all. Any updates on Apigee support for LetsEncrypt, specifically auto-updating of the certificate? It would seem that we would need to do the "separate linux box we control" steps above every time we need to update the certificate, which would not work for a production system.
I'm also looking forward to an automated solution. It's kinda sad that there isn't really an out of the box solution for this without resorting to like AWS Cloudfront for example.
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |