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

Hey, stay cool.

I definitely know how SSL works, but i think that we are talking about two totally different things...


Let me try it one more time:

The browser which is running on the UTM is a "totally normal" browser, and acts like the browser on your own desktop, right?

On the target server i have installed a certificate which is valid for "www.myapp.com", OK?

Now, the browser on the UTM opens the URL "192.168.1.123/whatever" which results in a warning, OK

Now, if i overwrite (replace) the IP with the hostname i have given in the configuration to match the certificate on the target server, the URL the browser opens results in "www.myapp.com/.../replaced) no warning will be shown because the host in the URL matches the host in the certificate.

It only changes the URL it opens, as you would do on the browser on your own desktop.
Access "85.115.22.3/" in your browser, you get a warning as expected.
Now, "overwrite" the IP with the hostname => "www.astaro.com/" => works fine

The browser on the UTM isn't doing anything else... Or am i wrong??

Hi,

Hey, stay cool.

I'll try... ;-)

Now, if i overwrite (replace) the IP with the hostname i have given in the configuration ...

The "name" is a label only. It's only purpose is to help the user to differentiate different things when he is using objects, by providing a human readable, display friendly name. It's easier to refer to "My Mailserver" than to "123.45.67.89".  You can even leave the "name" field empty, which results in an autogenerated name that starts with "REF_". We cannot use this as a DNS name. It's too unreliable and too inconsistent with the rest of the product. To define a host object that is identified by a DNS name, you _HAVE_ to use an dns-host object.

If you insist on using a Host-Object (which is used to store IP-addresses) instead of a DNS-Host-Object, you still have another option: changing the certificate of the server that you are trying to connect so that it includes the IP-address as an "Subject Alternative Name"

Or am i wrong??

Well, in the original post Adrian asked "But wasn't the fetching process ensure the correct cert is used ?". I think we've sorted that out now.

Later on, you asked "I don't understand why the certificate should become invalid if it overwrites the hostname...". I'm pretty sure that this is the place where the I misunderstood you. Since we were talking about certificates, I assumed that you would like us to overwrite the hostname that is stored in the cert itself, which we both agree isn't possible (or at least isn't feasible).

I don't see any chance for your idea (using the display name as the hostname) to be considered as feature, but I'll talk to the documentation department and try to get this into the online help, okay? 

Cheers,
Kai

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.

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

Why don't you use a dns-host object inside the html5 VPN connection and use a static dns mapping for this exact hostname to bind it to a specific ip adress, that can also be different than the normal resultion of this hostname on the Internet.

Just a thought
Gert

Just wanted to have a clean easy way to make HTML5 VPN work with SSL sites, without the need for an additional DNS-Host for a server i have a definition already. I have more than enough definitions anyway, don't want to have two definitions for the same machine.

So, unfortunately unusable for me for SSL sites.