Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 13 replies
  • Subscribers 1 subscriber
  • Views 4020 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

HTTPS error - Mismatch Hyper-V IP and host IP for WebAdmin

ShadowHunter
Hello, 

I’m trying to resolve a minor annoyance with WebAdmin accessed in local network. 

[LIST=1]
  • UTM runs in Hyper-V and WebAdmin is accessed via 192.168.1.110:4444
  • Hyper-V runs on Server 2012R2 on 192.168.1.115 (name: server_1)
[/LIST]

When I download the webAdmin certificate and install it on the PC from where I access WebAdmin I receive the warning that I’m trying to access 192.168.1.110 but that the server identifies itself as “server_1”, I already issued certificate via Remote Access on IP but obviously this was not working...

How should I resolve this? Any thoughts are most welcome.

Thank you [:D]

ShadowHunter


This thread was automatically locked due to age.
  • 0
    How do you have set the host name (Management -> System) of your UTM?
  • 0
    Yes, I think scorpionking has nailed it again.  See if following The Zeroeth Rule in Rulz solves your issue.

    Cheers - Bob
  • 0
    Hi, thanks for your help.

    It is simply set to "server-sophos1"

    Reading the Zeroeth rules I still cannot comprehense how I can get the Hyper-V IP (192.168.1.110) to not  being identified as "server_1", being "192.168.1.115"

    Any pointers?

    With best regards,

    ShadowHunter
  • 0
    Argh, now I've done it... I must have fiddled a bit to much with the UTM HTTPS certificates and now when trying to access WebAdmin Chrome informs with error:

    NET::ERR_CERT_INVALID

    And won't let me proceed... I can now only login via Hyper-V (as root under Linux)

    Please tell me that I don't have to reinstall the UTM and that I can fix this via the CLI
  • 0
    Hi,

    Okay, so far I changed the hostname and regenerated the WebAdmin certificate, against all advise I just used the internal IP not a FQDN as it is a simple home network here.

    The certificate was installed on the PC used to access WebAdmin.

    Now I get this rather strange error in Chrome:



    It is driving me nuts not being able to solve this [:S]

    Thanx

    ShadowHunter
  • 0
    Hi

    You can't use a IP Adress for your Hostname if you use certificates because IP Adresses are not supported. Use a FQDN instead.

    Regards,
    Michael
  • 0 in reply to ShadowHunter
    Hi,

    Okay, so far I changed the hostname and regenerated the WebAdmin certificate, against all advise I just used the internal IP not a FQDN as it is a simple home network here.


    You can always access Webadmin with IP address, if that was your concern, so it doesn't matter what you put in the Hostname field in your simple home scenario.

    But obviously, as Michael noted, you have to put some FQDN (utm.local or similar) instead of IP address.
  • 0
    With DynDNS, you can have a free hostname that is resolvable in public DNS, and that's what you should do.  Visit FreeDNS and generate an FQDN like utm.familyname.twilightparadox.com, and then follow the Zeroeth Rule.  Also, you will be happier if you put your modem into bridge mode so that you can have your public IP on the External interface of the UTM.

    Cheers - Bob
  • 0
    Hi,

    Thank you for pushing my in the right direction [[:D]]

    I don't need to access WebAdmin externally thus I changed the host name to a "shadowhunter.utm.int" and regenerated the HTTPS certificate using the same FQDN.

    Next I added a static DNS entry for 192.168.1.110 - shadowhunter.utm.int...

    Now I login with https://shadowhunter.utm.int:4444 and the warnings are gone, what a breeze now to login without clicking away all the warnings [[:D]] 

    Thank you so much for replying to this thread. It all seems so logical now [8-)]

    With best regards,

    ShadowHunter
  • 0
    You shouldn't even care about internally resolvable FQDN. As I said in my previous post, you can access Webadmin with IP address and add it to browser security exceptions (scrshot).

    Anyway, it looks that you have to put some FQDN in Hostname field.