[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

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