Apigee, Letsencrypt and http

We have setup a number of virtual hosts with domains we own for hosting endpoints on Edge Cloud.

I set them up with Letsencrypt certificates using DNS challenge however the DNS provider we have doesn't support API based changes so it was a manual step to get them setup first time. I had assumed that it would renew using the same challenges but that doesn't seem to be the case and we need to update the new challenges.

So instead I thought we could try using http based auth and a manual hook to upload the challenges either to a KVM or a jsc file in an API Proxy under /.well-known/acme-challenge/

However for that certbot requires that the host is listening on http on port 80.

For the cloud we can't seem to add additional virtual servers listening on port 80 to point to our same proxies. As it seems to be hard-coded to only allow a listener on port 443.

For me there would be 3 ways to solve this:

1) Apigee would support letsencrypt natively, and all the customer would need to do is setup a DNS cname from their own domain to point to the xxx-test.apigee.net domain based on your organization. Then using standard certbot Apigee would be able to auto-renew the certs as they could use http hosts and it would all just automatically renew.

2) Apigee supports adding http port 80 virtual servers. Then we could have a virtual server for https-company pointing to api.company.com and another virtual server for http-company pointing to the same proxy but over http.

3) Allowing the "default" virtual server to have additional virtual server aliases. I can add an alias for all the https endpoints, but I can't add an alias for the http one.

Any other suggestions on how to work-around this other than going through the manual DNS renewal process with letsencrypt/certbot??

Solved Solved
0 3 631
1 ACCEPTED SOLUTION

@srinandans FYI

Yes I understand the problem you're facing.

Your 3 possible ways to solve the problem seem correct to me. Of the three I prefer #1; it's easiest and would be easiest to describe. But that's just my opinion.

It will not satisfy you at all, but there is an outstanding request for this exact feature. b/70583295

In the past I have solved this by moving my DNS around to a different (not Apigee) host that I control. (I suppose you understand what I mean here, but if not, let me know) . In general, This is not a viable approach as it means an outage during the ACME challenge/response. But if you can tolerate a "maintenance window" on your service, you will be able to refresh the cert via ACME.

I'm sorry I don't have a better answer right now.


[Edit 20190702-1014] After further consideration, there is another alternative. You and I are discussing the HTTP Challenge. But you could use the DNS challenge; it would require no change to the router, vhost, or vhost alias within Apigee Edge. This might be your best bet right now. We're still discussing how we might update the Apigee Edge product to make it easier to use the HTTP Challenge.

View solution in original post

3 REPLIES 3

@srinandans FYI

Yes I understand the problem you're facing.

Your 3 possible ways to solve the problem seem correct to me. Of the three I prefer #1; it's easiest and would be easiest to describe. But that's just my opinion.

It will not satisfy you at all, but there is an outstanding request for this exact feature. b/70583295

In the past I have solved this by moving my DNS around to a different (not Apigee) host that I control. (I suppose you understand what I mean here, but if not, let me know) . In general, This is not a viable approach as it means an outage during the ACME challenge/response. But if you can tolerate a "maintenance window" on your service, you will be able to refresh the cert via ACME.

I'm sorry I don't have a better answer right now.


[Edit 20190702-1014] After further consideration, there is another alternative. You and I are discussing the HTTP Challenge. But you could use the DNS challenge; it would require no change to the router, vhost, or vhost alias within Apigee Edge. This might be your best bet right now. We're still discussing how we might update the Apigee Edge product to make it easier to use the HTTP Challenge.

Thanks Dino, much appreciated.

So far the options I am investigating is either creating a delegated subdomain with another DNS provider, or potentially moving the whole domain to them as they support updating the DNS TXT records via API so I can update the text challenges that way. Or swing the CNAME record over to my own non-Apigee host and do the challenges that way creating an outage at that point.

Or I did look at ALPN challenge but all of the example code I have seen needs a bit of work as they all spin up a local openssl listener. So I think that might be more workable.

But if I could bind http on port 80 for the domain it would be easier to sort.

Further to this, I tried and failed to use the tls-alpn-01 challenge as well.

For the ALPN I need to upload a temporary cert that I sign and then provide to letsencrypt and it attempts to connect over 443 to the Apigee Edge.

However I am unable to negotiate ALPN to the Apigee edge, this is something that would also need to be configured within the nginx instance.

To test it I can use openssl:

openssl s_client -alpn acme-tls/1 -servername edgeurl.apigee.net -connect edgeurl.apigee.net:443

If it worked I would get this in the response: ALPN protocol: acme-tls/1

Otherwise you get: No ALPN negotiated

That would need to be enabled within nginx as per the following:

https://github.com/lukas2511/dehydrated/blob/master/docs/tls-alpn.md

So that is another way it could be solved, if Apigee edge supported it.