vManage web certificate (Cloud version)

[markus.albisser]

Hi all

We are setting up SD-WAN with vManage, vBond etc directly with Cisco in the Azure cloud. To access the webinterface now for vManage, we got the URL https://vmanage-company.sdwan.cisco.com. The web service by default has a self-signed web certificate active for the host "cisco.com". This access now results in a non-secure access within the browser, because the host name does not match and we don't have a valid chain with a root CA certificate which validates the certificate. This makes sense so far.

The question now is how do we go around this one. First we thought about two options:

1. Create a new official certificate (for example with Digicert). Either with the true hostname from the URL or then with this hostname as part of the SAN field. A chat with Digicert brought it up that it is not allowed to enroll certificates for which we are not the owner of the domain - in this case cisco.com.

2. Create a certificate within our internal CA. Also here, same topic, we cannot enroll a certificate for a domain which is not part of our environment. Futhermore, we cannot add the public key of our root CA certificate from our internal CA to the trusted root certification authorities. 

I am wondering what the solution is on this one. Why Cisco for example has not a wildcard certificate which would be valid for all the cloud customers (*.sdwan.cisco.com) or then provides host-based certificates which comes from a authorized public CA. I don't see how I can get around this, I cannot enroll a certificate by my own and continue with the self-signed is also not a true option (such a business-critical system should not result in a "not secure" browser statement).

Any thoughts and inputs are appreciated. Many thanks!

Markus

[Lei Tian]

Hello Markus,

We have raised the concern before, currently cloudops team doesn’t have this on roadmap. I suggest you reach out to your Cisco account team if you have one, or open TAC case with cloudops team for this concern.

HTH,
Lei Tian

[markus.albisser]

Hi Lei Tian

Thank you for your feedback. This tells me that this is a true issue we have, without a good workaround which can be implemented. Let's see if there are other customers/persons with a similar experience and feedback. I discussed it already with your Cisco partner, probably then I will open a TAC case to address it.

Thank you
Markus

[Lei Tian]

Hello Markus,

The cloudops team currently doesn't provide sign web cert, but you might be able to use your own domain name for controller's FQDN and get signed. Open TAC case with cloudops team see what options do you have. 

HTH,

Lei Tian

[markus.albisser]

Hello Lei Tian

You mean of course it would be possible to have the URL we have today (https://vmanage-company.sdwan.cisco.com) replaced for example with https://vmanage.company.com, for which I can enroll then a certificate? I agree, this would solve the issue, if Cisco allows to go away from the TLD cisco.com. Did I got you correctly?

Thank you
Markus

[Lei Tian]

Hello Markus,

That's correct. You can ask cloudops team whether they can use customer domain name for controllers. Or you can point A record to your own domain name and CNAME to the cisco domain.

HTH,
Lei Tian

[daniel.dib · Accepted solution]

Hi Markus,

The way I usually approach this is to create CNAME in customer's DNS that points to Cisco's A record. So something like vmanage.example.com pointing to vmanage-xxx.sdwan.cisco.com. Then generate a CSR under Administration -> Settings -> Web Certificate. Put the Common Name as vmanage.example.com and also put it in the SAN.

Hope that helps.

Best regards,

Daniel

[markus.albisser]

Hi Daniel

This seems then to be an acceptable way to go. But do you know if Cisco's web service also accept when my request comes with any other hostname than the one which is expected? Normally, web services denies then the request or they then send a deny and redirect message back, which forces the browser again to ask the original hostname, which then will result in the same picture.

Thank you
Markus

[daniel.dib]

Yes, it works. I have this setup for a couple of customers. Seems that NGINX or what they are using for the web requests will accept any name.

[markus.albisser]

Thanks everybody for the feedback. I raised a case to get a formal answer from Cisco that this way with the CNAME is good to go. Once I got this confirmed I will then close this threat here.