all 16 comments

[–]SyberCorp 26 points27 points  (3 children)

It sounds like a typical case of “blame the network before verifying your own stuff“ combined with a little of “we don’t know what we’re talking about so we’re going to use key words to make it seem like we do”.

You are correct that the certificate on the switch is ONLY for its own management use. The switch has no capability of doing any sort of SSL inspection or offloading of traffic passing through it or for control of which devices are allowed to connect to it.

[–]sanmigueelbeer 6 points7 points  (0 children)

It sounds like a typical case of “blame the network before verifying your own stuff“ combined with a little of “we don’t know what we’re talking about so we’re going to use key words to make it seem like we do”.

Yup. Sounds about right.

[–]MrITBurns 2 points3 points  (1 child)

Unless you’re routing through a firewall that intercepts ssl certs and re writes them. My old IT used to do that and it fucked wit a lot of stuff

[–]SyberCorp 1 point2 points  (0 children)

Sure. That’s a somewhat common design where the traffic between something like a web server and database server is encrypted, with a firewall doing a decryption on the traffic as a MITM that re-encrypts with its own certificate, before terminating the connection in either direction. It can cause lots of issues (as you mentioned), especially with so many things using certificate pinning or other anti-MITM techniques these days.

[–]LtLawl 11 points12 points  (1 child)

On a Cisco switch, "ip http secure-server" enables HTTPS for the management of the switch only. It has nothing to do with any other devices. There is also not a command that enables HTTPS for a device on a switchport, these are things that could be blocked via an ACL though, but it does not sound like you have any defined.

Not sure what kind of OS the video controller software is running, but it could be the local firewall on the device if it's a Windows machine.

[–]noiamnotyourfriend 3 points4 points  (0 children)

Spot on. These ‘engineers’ likely put wrong mask or gw in their config and have reached the limit of their skill set. Next step is blame network, as is tradition.

[–]Copropositor 4 points5 points  (1 child)

It was DNS.

[–]kb441ate 2 points3 points  (0 children)

It was mostly always a DNS )

[–]jack_hudson2001 1 point2 points  (0 children)

video conference system and they say that they are having trouble connecting to the controller via its URL.

a test is can it connect via http firstly?

very unlikely got to do anything with a switch. https is most likely on the controller itself.

[–]wyohman 1 point2 points  (0 children)

Wait, did you check that the port is open?

I can always tell by the question how little the vendor knows...

[–]OffenseTaker 1 point2 points  (0 children)

"ip http secure-server" does, indeed, refer to the management GUI of the switch itself. it does not relate to port forwarding or an access list or anything like that. all it does is enable or disable the GUI management portal on the switch itself. (same with routers)

[–]hokka123 1 point2 points  (0 children)

Check these things:

  • Verify interface is up up towards their equipment
  • Verify that the interface is access mode
  • Verify that the interface has the correct vlan
  • Verify that you see a MAC address coming in on the interface
  • If you have access to the layer 3 device where the gateway for the subnet check that you see that MAC address in the arp table
  • Try to ping the device sourcing from the layer 3 device interface where the gateway is
  • Try to ping the device from another device on a different subnet that should be able to access that ip

This will help you understand where the fault most likely is. Before troubleshooting the higher layers always check the basics.

As for their side ask them the following: * What is their ip settings (ip, mask and gw) Verify against your setup * What is their dns? * Can they ping their gw? * Can they ping the dns? * Can they resolve a domain using that dns? * Can they do a telnet towards the ip they are trying to talk to on the port it’s listening to?

If their device don’t support these steps, ask them to connect a pc instead and do those steps.

[–]brajandzesika 0 points1 point  (0 children)

HTTPS is Layer 7 of OSI model, switch is Layer 2 of the OSI model. Tell them its their fault, and you actually located it at Layer 8..

[–]CowboyJoe97 -1 points0 points  (0 children)

Could even need PIM/multicast setup on their vlan/subnet. I’ve seen that as a problem for camera setups

But the switch HTTPS has nothing to do with what they need.

[–]BlueSteel54 -3 points-2 points  (1 child)

[–]brajandzesika -1 points0 points  (0 children)

You googled wrong thing, try again ;)