Thread Info
  • State Not Answered
  • Replies 16 replies
  • Subscribers 0 subscribers
  • Views 3810 views
  • Users 0 members are here
Options
Suggested

[8.900][MYTH] Clientless VPN Webapp (https) invalid cert warning

adriand
Added a Webapp (HTTPS) Clientless SSL VPN Connection; for OWA 2003.
Defined the destination as Host(IP addr).
Path /exchange/.
Fetched successfully the SSL certificate.
Saved the connection.

Connected to the user portal and clicked the OWA connection; browser was Firefox 10.0.2 or Chrome 17.0.963.5(Windows 7).

The "inner" Firefox throws an invalid cert warning; for the server's name. See the attached screenshot.

But wasn't the fetching process ensure the correct cert is used ?

Did not try yet to use instead of a Host(IP addr) a DNS Host for the destination of the Clientless SSL VPN Connection.

Thanks,
Adrian
Parents
  • 0
    Ahhhh... We're getting closer :-D

    I don't wanted to use the name field for replacement, but an additional (new) field which is optional and where you can set (override) the IP with a hostname if you want to. The same way as it is done f.ex. for SSL VPN (Remote Access => SSL => Settings => Override hostname). Then you don't have to use a "DNS host", but you still can.

    "I don't understand why the certificate should become invalid if it overwrites the hostname..." was a really bad sentence... I of course meant the hostname of the URL, not the certificate...


    The URL is generated by the object of the destination host and the additional path by default. If you simply would take the hostname of the new additional field i would like to have instead of the information of the destination object (if there is a hostname in the new field), the URL would be a nice clean FQDN. I think that would be an easy way to make SSL sites work over HTML5 VPN.
Reply
  • 0
    Ahhhh... We're getting closer :-D

    I don't wanted to use the name field for replacement, but an additional (new) field which is optional and where you can set (override) the IP with a hostname if you want to. The same way as it is done f.ex. for SSL VPN (Remote Access => SSL => Settings => Override hostname). Then you don't have to use a "DNS host", but you still can.

    "I don't understand why the certificate should become invalid if it overwrites the hostname..." was a really bad sentence... I of course meant the hostname of the URL, not the certificate...


    The URL is generated by the object of the destination host and the additional path by default. If you simply would take the hostname of the new additional field i would like to have instead of the information of the destination object (if there is a hostname in the new field), the URL would be a nice clean FQDN. I think that would be an easy way to make SSL sites work over HTML5 VPN.
Children
  • 0 in reply to UrsWeiss
    Ah, an additional form field. Interesting idea... but

    ... I think that would be an easy was to make SSL sites work over HTML5 VPN.


    You would still need to have a DNS configured correctly on the UTM to allow the browser to resolve what you'd then have configured for that SSL site. 

    I don't see any benefit in pretending that you could get around a correctly configured DNS by simply adding another form field there and i think this would  confuse users even more than a clear rule that says "use a DNS-Host object in this case".

    Cheers,
    Kai
Cookie Information Banner