Forum Discussion
Can LTM help to save on SSL certificates on different common names?
Dear all,
F5 had recently replaced Brocade and Microsoft Forefront Threat Management Gateway (Forefront TMG). Customer has many subsidiary companies and has its own domain names. They all point to a public IP and in term being NAT-ed to F5's VIP. There was an SSL cert in this virtual server and is currently presenting mail.abc.com. That is why no security warning when user browses to mail.abc.com/owa on a browser.
Customer was unable to tell me what TMG is doing for their environment and he wanted F5 to help with the below issue
The issues lies with Outlook Clients connected to external networks, for example employee works from home and is away from their internal network.
There is a security warning prompt on Outlook which looks like:
Customer told me there wasn't any issue before F5 came into the picture. I nearly wanted to tell him he should buy additional SSL certs but realized he has too many subsidiaries in his environment, connected to his exchange server farm.
This issue occurs whenever user setup email client via autodiscover and it pops up occasionally after the email has been setup. User just needs to click YES to acknowledge the warning and they are good to go. But it keeps popping up now and then.
Samir_Jha_52506Noctilucent
I am suspecting
is CNAME of autodiscover.abc.com & some where users are using autodiscover.abccommodities.com to call owa client. I guess you can mitigate via two ways.autodiscover.abccommodities.com1) Check the email client via autodiscover setting on user machine & update correct name.
or
2) Purchase new SAN certificate & add name
in also.autodiscover.abccommodities.comDoesn't it make sense? Please update
Yes it makes sense.
Does this scenario makes sense? Whenever users use autodiscover to setup Outlook client by keying in user@abccommodities.com and password, Outlook tries to retrieve info from autodiscover.abccommodities.com but realized the other end has certificate for autodiscover.abc.com, thus the security warning.
Solution is to have certificates installed on F5 since all autodiscover traffic goes to the virtual server.
So in F5, does it make sense to redirect autodiscover.abccommodities.com to autodiscover.abc.com as its first autodiscover process. Which may mean we need to inspect traffic at HTTP layer.
I am exploring solutions here on F5, exhaust them before I tell customer there is nothing we can do at F5 side. Which makes me wonder can Microsoft TMG do this?
inox_358573Nimbostratus
Hello,
did you find a solution to this issue in the end? I'm facing a similar issue.
Thanks.
R__Hickman_1172Looks to me like autodiscover.abccommodities.com could possibly be the external domain name and autodiscover.abc.com is the internal. I'd check to see what your autodiscover DNS record looks like internal - it may be going to autodiscover.abc.com and so the cert is valid for that. If you want your cert to be valid for both abc.com and abccommodities.com you have to have the autodiscover.abccommodities.com in your SAN list. TMG is a Microsoft product and likely compensated for the cert mismatch whereas F5 does not.
Looks to me like the solution is to generate a new CSR, add autodiscover.abccommodities.com to the SAN list for the cert, generate the cert, and then swap the cert out on the F5 as well as your Exchange servers.