hawks76
Enthusiast
Enthusiast

HTTP-Plugin Request to Load Balancer with Host Header

Jump to solution

I'm calling an internal API endpoint that sits behind a load balancer.  Sometimes, it returns this error:

Cannot execute the request: ; Certificate for <****************tesportal.rgbk.com> doesn't match any of the subject alternative names: [*****WEB06.corp.rgbk.com, *****WEB06]

I have the RestHost pointing to the ****************tesportal.rgbk.com. Most of the time, i can simply rerun the workflow and it completes successfully.  After reaching out to our web farm team, they suggested i need to send a host header as part of the call because it's on a shared farm.  I set the host header like this:

request.setHeader("host","****************tesportal.rgbk.com");

but that doesn't seem to help at all.  Odd thing is, i have a test workflow that calls this same exact endpoint, in the same manner with all the same settings, and i haven't gotten this error once.  I've combed through the setting over and over, but they are exactly the same.  

Any help on this is greatly appreciated.

Thanks

0 Kudos
1 Solution

Accepted Solutions
hawks76
Enthusiast
Enthusiast

So, turns out that the IIS site this API is hosted on had an expired certificate that was bound to the default website.  It got deleted, but still presented the expired cert.  servers go patched and rebooted, and after valid certs were bound to the default site, everything worked as expected.

what i believe was going on was the API call was actually pulling the valid certs, but vRO was hitting the default website (due to vRO not sending host header when pulling the certs) and thus pulling the expired certs, thereby creating the cert mismatch and giving the error that i was seeing.

View solution in original post

0 Kudos
7 Replies
xian_
Expert
Expert

Try to set the RestHost not to check the cert:

xian__0-1615326255839.png

 

0 Kudos
hawks76
Enthusiast
Enthusiast

I've done that.  It didn't help.

0 Kudos
xian_
Expert
Expert

Do the load balanced servers have different certificates when they respond? vRO stores the trusted certs when you add the endpoint, but might not have all the possible certs trusted and stored.

0 Kudos
hawks76
Enthusiast
Enthusiast

Not according to the Web Farm guys.  The actual servers have SSL certs (that are expired) but they said that doesn't matter cause it should be using the Load Balancer Cert.  The odd thing is it's only intermittent.  I've checked in the control center and the cert for the load balancer is there and valid.  They said i need to send the host name, but i don't know if i have it set right in the header mentioned above. I can't find any documentation on that particular header for vRO.

0 Kudos
xian_
Expert
Expert

Try the Host header with capital H

0 Kudos
hawks76
Enthusiast
Enthusiast

I've tried with both host and Host.  Also tried with the version on the SSL cert that had capital letters in it.  So far, none of that made a difference.

0 Kudos
hawks76
Enthusiast
Enthusiast

So, turns out that the IIS site this API is hosted on had an expired certificate that was bound to the default website.  It got deleted, but still presented the expired cert.  servers go patched and rebooted, and after valid certs were bound to the default site, everything worked as expected.

what i believe was going on was the API call was actually pulling the valid certs, but vRO was hitting the default website (due to vRO not sending host header when pulling the certs) and thus pulling the expired certs, thereby creating the cert mismatch and giving the error that i was seeing.

View solution in original post

0 Kudos