Loading Profile...
EMPLOYEE
HTTPS / SSL Solution Proposal
People: API providers, API consumers
Problem: cannot use HTTPS/SSL to encrypt API requests and responses with Apigee
Proposed Solution Overview: provide support for HTTPS with 1-way SSL certificates. 2-way SSL certificate support will not be offered immediately.
Proposed Solution for API Consumers:
Apigee would open the HTTPS port (443) and provide a wildcard SSL certificate, *.apigee.com. Developers consuming APIs would have their requests and responses encrypted from the client to Apigee and from Apigee to the target API. For example, a request to the Twitter API using Apigee would use a URL like:
Proposed Solution for API Providers (with DNS Domain Mapping):
Apigee would open the HTTPS port (443) and the API provider would need to upload a public SSL certificate to Apigee. Requests and responses would be encrypted from clients to Apigee and from Apigee to the target API. A developer using Apigee would make requests with URLs like:
Proposed Solution for API Providers (with Reverse Proxy on HTTP Server):
Apigee would open the HTTPS port (443) and provide a wildcard SSL certificate, *.apigee.com. Requests and responses would be encrypted from clients to Apigee and from Apigee to the target API. A developer using Apigee would make requests with URLs like:
Proposed Solution for API Providers (without Domain Mapping):
Apigee would open the HTTPS port (443) and provide a wildcard SSL certificate, *.apigee.com. Requests and responses would be encrypted from clients to Apigee and from Apigee to the target API. A developer using Apigee would make requests with URLs like:
Problem: cannot use HTTPS/SSL to encrypt API requests and responses with Apigee
Proposed Solution Overview: provide support for HTTPS with 1-way SSL certificates. 2-way SSL certificate support will not be offered immediately.
Proposed Solution for API Consumers:
Apigee would open the HTTPS port (443) and provide a wildcard SSL certificate, *.apigee.com. Developers consuming APIs would have their requests and responses encrypted from the client to Apigee and from Apigee to the target API. For example, a request to the Twitter API using Apigee would use a URL like:
https://my-twitter.apigee.com/statuse...The developer would not be required to perform any additional steps to support SSL.
Proposed Solution for API Providers (with DNS Domain Mapping):
Apigee would open the HTTPS port (443) and the API provider would need to upload a public SSL certificate to Apigee. Requests and responses would be encrypted from clients to Apigee and from Apigee to the target API. A developer using Apigee would make requests with URLs like:
https://api.alohacrm.com/accounts.json Important: for DNS Domain Mapping the API provider must upload to Apigee the public SSL certificate for the domain being mapped, for example api.alohacrm.com.
Proposed Solution for API Providers (with Reverse Proxy on HTTP Server):
Apigee would open the HTTPS port (443) and provide a wildcard SSL certificate, *.apigee.com. Requests and responses would be encrypted from clients to Apigee and from Apigee to the target API. A developer using Apigee would make requests with URLs like:
https://alohacrm.apigee.com/accounts....Assuming the API provider already has a SSL certificate on his API servers, he would not need to take any additional steps.
Proposed Solution for API Providers (without Domain Mapping):
Apigee would open the HTTPS port (443) and provide a wildcard SSL certificate, *.apigee.com. Requests and responses would be encrypted from clients to Apigee and from Apigee to the target API. A developer using Apigee would make requests with URLs like:
https://alohacrm.apigee.com/accounts....Assuming the API provider already had a working SSL certificate on his API servers he would not need to take any additional steps.
I’m happy
8
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company implemented this idea.
The best point from the company
-
Update: we now have SSL support for the first and last case in Brian's proposal, details available on the blog. As always, feedback welcome!
The company thinks
this is one of the best points
-
Inappropriate?Sounds cool... would our certs that publishers send to you need to be signed properly, or could we use self signed certs?
I’m excited
1 Comment Add a comment
This is one of the best points
-
yes it can be a self signed cert too. -
-
Inappropriate?A co-worker and I were just discussing the lack of SSL when using apigee this would be great.
I’m happy
1 Comment Add a comment
This is one of the best points
-
Mike, you can now proxy an SSL API by prefixing the setup URL with "https://". See the blog post for more details.
-
Inappropriate?Hi, your FAQ mentions:
You can continue to use your existing API identity, authentication and authorization scheme with Apigee. If you currently use developer keys, you can use these with Apigee.
As an API provider, if I currently use 2way SSL with signed digital certs and user/pass then is it possible to set up apigee with the cert and with the user/pass details so that developer can send an unauthorized request to apigee and have apigee send a secure request? I couldnt see this in the API setup/config.6 Comments Add a comment
This is one of the best points
-
Hi brettser,
at the moment we are building out the solutions specified above for 1-way SSL. once we finish those, we'll turn our attention to 2-way SSL.
Would you be up for giving us feedback once we craft our solution proposal for 2-way?
-b -
Yes - absolutely
-
awesome. we'll be in touch.
-
Hello brettser,
to Make sure i got your problem. You have an api which uses HttpBasic Auth ( assume thats what you mean when u say u have uid/pwd) and to encrypt the above credentials you use two way SSL.
Couple of questions:
1) with apigee do you still need two way SSL, u can authenticate that the request came from the client without using Two way SSL since apigee is a proxy all requests will be coming from a static IP.
2) Can you explain the following statement "developer can send an unauthorized request to apigee and have apigee send a secure request". do you want to expose a unsecure api for a secure api and why would you want to do that.
One way of solving your use case would be proxy your api with apigee using 1-way ssl and exposing a secured 1 -way ssl with the developer.
so the developer can send a authorized request which will be encrypted ( since he would be using a secure api) and the credentials are forwared to your endpoint using 1-way ssl.
please let me know your thoughts and if that solves your use case -
Manoj, in point #1, will the pool of static addresses grow in the future? What if we migrate to a new data center?
-
Hey Marsh,
when we move to the new data center we would do a reverse NAT so for an endpoint it would look like coming from a single IP.
Hope that answers the question. -
Inappropriate?Update: we now have SSL support for the first and last case in Brian's proposal, details available on the blog. As always, feedback welcome!
The company thinks
this is one of the best points
-
Inappropriate?Your guys' ssl thing does not work.
-
Inappropriate?It forces me to use
*.company.apigee.com
for my apigee api url, and that does not allow my cert to work correctly.
please email me! I can't use the service -
Inappropriate?Hi, I can't appear to use this.
I have an api that looks as follows:
"https://api.postalmethods.com/2009-09..."
I created an api proxy in apigee, putting in the https. But what I get back is an error, saying OPEN SSL error, cannot match hostname.
I’m frustrated
-
Inappropriate?Hello Timothy,
we currently support ssl endpoint as https://..apigee.com. However as you duly noted that this does not match the hostname because according to the RFC *.apigee.com does not match to *.*.apigee.com and the hostname verfication fails.
we are in the process of deploying a solution to fix this where in you can access a ssl endpoint as -.apigee.com i.e. assuming you domain name is test it would be postalmethods-test.apigee.com.
this solution is going to go live by 08/03.
In the meantime if you can disable host name verification in your code this would give some relief till next Tuesday.
Hope that answers your question. -
Inappropriate?Hi, is there a way I can set my endpoint to just *.apigee.com? Seems like since that was set, there's a way to do that, maybe?
Otherwise, how do I disable hostname verification in my code (ruby on rails)?
Thanks.
I’m confused
-
Inappropriate?some months back we introduced the concept of a domain name as a namespace qualifier to qualify the proxy names in order to avoid proxy name collision.
as i mentioned please wait till 08/03 we would deploy the change to allow access to ssl endpoints as -.apigee.com
in the meantime for disabling hostname verification in ruby can u try this.
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
EMPLOYEE
EMPLOYEE
