Cannot update certificate on Virtual Host

Hi Support,

In our Apigee account (vidyo-inc), our certificate expired so we did all of the steps given in your documentation - update TLS Keystores and update Virtual Hosts. And on top just to be sure, we also undeployed and redeployed our API proxy. However, none of it seems to update the certificate when accessing our proxy. My thought is that something is wrong and we need you to check on your side what might be happening. Can you please check and let us know as soon as possible? We are blocked on the work we are doing as we cannot get this to work.

Regards,

Vimal Naik

Enghouse Vidyo

0 9 420
9 REPLIES 9

What does this mean exactly:

However, none of it seems to update the certificate when accessing our proxy.

What did you do, that lead you to draw that conclusion?

Are you using REFERENCES as the documentation recommends? If not, that could be the issue. Please show the specific configuration of the vhost. Is it one-way or 2-way TLS?

It sounds to me that you should open a support ticket and ask the Apigee support staff to investigate and assist. If you're not using References, then... it's possible you (on your own) could create a new vhost which uses a ref to a keystore... and delete the old vhost, and modify all your proxies to use the new vhost . If that is not feasible or does not work, then.... you will need Apigee support assistance to update the cert on the existing vhost. And then you should convert to references.

If you are using References, then... there is something else going on and you'll need assistance from Apigee support in diagnosing it.

Thank you for your guidance,. I apologize for my ignorance but I ended up here after going through a few links which talked about contacting support. But I can't seem to exactly find a way to contact support. What is the proper way to get to Apigee Support? I actually have a paid account so I assume we should get support.

Yes, you should have a way of contacting Apigee Support! Unfortunately I am not a paid customer and I don't know exactly how that works, but I THINK it involves a "support portal" web UI. You login with the credentials that Apigee gave you when you purchased; and then you open a ticket through that UI.

Can you check your email archives to see an email from Apigee describing this?

In the meantime have you considered deleting the existing vhost and creating a new one with the right certs and references?

Thanks again. I got an error trying to delete the Virtual Host as it said that it was in use. What I am afraid of is that if I change too many things, it will somehow change my API Proxy (which was originally designed by a previous colleague who is no longer with the company). But in order to delete Virtual Host, do I basically just have to undeploy the proxy app, then delete virtual host, then recreate virtual host, and then redeploy the app? Or is it more complicated than that?

yes, "In use" means you have at least one API Proxy that refers to that vhost AND is currently deployed.

I understand you're concerned about making too many changes and damaging your configuration.

Maybe try it this way:

keep the existing vhost for now.

Create a new vhost (with the Reference to the new keystore) and then also create a new "smoke test" API Proxy; this will be used only to verify the behavior of the vhost. Within that new API Proxy refer to that new vhost.

Deploy and Test that new API Proxy. (It doesn't have to do anything; it can be a loopback proxy, just returning a static response). If it works (returns the right cert/key or whatever), then you know your new vhost works.

The catch is ... you cannot use the same hostname on 2 distinct vhosts. There's got to be a unique hostname. So if your current vhost uses api.mycompany.com, you cannot use that on the new vhost. you need to use api-new.mycompany.com or something distinct.

Later, after your tests confirm that the certs are correct on the new vhost, you could undeploy all proxies, convert them to use the new vhost, and then remove the (api.mycompany.com) hostalias from vhost-old add that same host alias to vhost-new. Then redeploy the proxies. And that should get you there. But following this path means there will be a service outage on your APIs for the length of time you have the proxies undeployed.

You could sort of test this last part with a "test" proxy that isn't actually in use by your customers, to confirm that you're doing the right thing. And then finally do it with your "real" proxy.

Apigee Support could walk you through all this, if you can get them on the phone. (Not sure if your support plan includes that level of service.)

Thank you for the detailed info. I will go with this plan.

Hi Dino-at-Google. We actually had a lot of proxies deployed (most are probably test related) so I actually got brave enough and decided to undeploy them and just delete and recreate the virtual host (along with the new certificate details). And then go back and redeploy my main proxy. But I still see the expired certificate being presented by the virtual host. But there is one difference so far but I am not sure it is the cause of the issue. For the virtual host, we have a "default" one for port 80 and a "secure" one for port 443 (with the certificate). So is it that I need to delete both of them? I only deleted what I had to so only deleted the one for port 443 but the alias was set on both of them. So I was wondering if I have to go and delete both and recreate both?

I suggest you create a new vhost with a new name. Not "recreate" the vhostnamed "Secure" . Create one with a newname. And Use THAT.

I am afraid that there are multiple pieces involved in the APigee service, and in some cases some of the pieces may cache or retain information based on the name. So you need a new name.

And if you have a white-label domain, you will need to remove the host alias from the existing "secure" vhost, and add the white label host alias to the new "secure-new" or "secure-2" vhost. Also modify all proxuies to listen on "secure-2" vhost.

Thank you for all of your advice and help. I was able to learn a lot through it. Ultimately though, I was not able to resolve this issue and ended up getting our support account generated in the Apigee customer portal and then they were able to do something manually to address this issue. I would have tried many more steps but the combination of things were a bit too much. Apigee Support didn't provide too many details on exactly what they did but my problem is now resolved as the new certificate does appear for our virtual host now. Once again, thank you very much for all of your support.