Messages

Those cloud services were designed for home users allowing them to share their vacation photos. Those haven't been (publicly) audited to use in a business environment. As a security manager, I get scared when management comes up with the idea of using Dropbox or Google Drive to share sensitive files. Call me old-fashioned, but I still prefer local storage. An audited private cloud might be an alternative.

This seems true (using existing AD leverage to get foot in the door) but its also their greatest problem - the army of retarded MCSEs that have to build and administer it.
Have observed multinational MSP struggle with a 2 day Lync outage because a cert expired and it basically took 2 days to get a non-braindead 'level 3' engineer who understood basic PKI (of course, they managed the CA as well, standard enterprise CA model). Also, lord help you for any SIP/SBC related issues or changes.
You think its bad getting router guys to dabble in VOIP? Wait till you watch MS jockeys try it. I'm not even going to start on QoS ROFL.... Throw in the generally poor level of 'tech' that exists in the MS realm and its fun times

I've seen MCSE and even MCITP guys panic when they where presented with a CLI (before the MS Powershell era). And they call themselves IT Professionals. In my opinion an IT professional should be able to work with Windows, Linux (especially using the CLI), know at least one scripting language and have some understanding (at least basic understanding) of networking, troubleshooting and PKI.

I remember an issue where we had a conflicting ARP entry in one of our switches due to an IP conflict. One of my colleagues (who is MCITP certified) was surprised that he found this conflicting MAC address in all the other switches on that broadcast domain, as he was under the assumption that MAC addresses don't pass a switch because they would be NAT'ed somehow. And they call themselves IT professionals 

You don't need internet access if your appliance is doing SSL offload/termination provided that you have a certificate bundle that has a chain certificate issued by the CA and a signed certificate from the CA.  You will need this to be stored on the trusted storage on that appliance.

https://en.wikipedia.org/wiki/Intermediate_certificate_authorities

You should able to find the process of how to do this from the appliance vendor config/manual.  Often you will need to use openssl CLI to verify if the chain of trust is working or not.

The chain has been loaded in the Trust Store. What's even more weird is when I plug that same computer in our local switch (circumventing the WAN), it's not having those issues.

It was my experience (this  was with a cert from another vendor, but still pre-installed on browsers) that if our guest wireless pre-auth ACL did not allow DNS to an external DNS server and HTTPS to the CA of the vendor, devices would get a cert error on the HTTPS connection to the guest logon webpage. When I saw internal Macs having no issue and Macs in a controlled area having an issue, that was my first thought.

Try opening up those ports, anyway, and see if it works. If not, well, I'll learn something new. 

I'll check with the provider to see if they can open this up. It's a huge telecom company in my country, and their engineers are noobs. I've one had an issue with them where traffic from one of our appliances was being sent to an unknown IP address. After investigating, we had to tell them that the IP address in question was the NAT address of their main firewall. Each segment of the network is being maintained by a different department. They even have firewalls within Trust zones...

Are they by chance using a proxy server in their browser? How about DNS, are they internally forwarding to your internal nameservers?

I've verified the proxy configuration, and none is configured. Their DNS servers have been made authorative for our domain, having its records point to our internal IP addresses.

Have they by chance tested from that exact same location with a Windows box instead of Macs? Are their browsers configured to use the right version of SSL/TLS?

Yes, that has been tested as well. Google Chrome shows the same error. Internet Explorer does not, and loads it normally. The appliance supports TLS 1.0 and above. Mac OS X supports this since 2002.

Hi there neighbour!

Literally, I live 2.5 miles away from your border

I've been working with both sides (Microsoft Lync and Cisco Jabber), and Lync is absolutely horrible to implement. We've spent over a year to deploy this, together with several Microsoft Gold Partners. Cisco Jabber has been much easier to implement for us. We provide this for our customers, so we use these environments daily. Microsoft on the other hand is still going to win this, mainly because they already have a foot in the door at most companies. I've spoken with different people at Microsoft, and they have this strategy of offering Lync at a discounted price or even for free. That's something Cisco can't compete against. This will be the same battle as the web browser battle in the 90s between IE and Netscape. Netscape was much better, but IE won because it was shipped with Windows (which almost everybody was using already).

I'm not really experienced with the CUCM, but on Tandberg/Codian equipment a participant limit means that all connections above that limit are dropped. Audio-only participants are usually only created when exceeding the ports (screen license) limit.

Hi everyone,

I'm Roy and I'm from the Netherlands Been working with computers since the age of 6 (mostly programming), and been interested in computer security since a young age. I started my career doing (security) research for the government. Didn't really enjoy that, so for the last 5 years I've been working at a Telepresence Cloud provider as security specialist, network architect and developer.

I have just tried something to test this theory. Had a computer connected to that network, and made sure that it didn't have any other connections. Even removed the default gateway, so it would definitely not be possible to reach the Internet. When I enter the FQDN of the appliance (I've added the FQDN to the Hosts file), I don't get a certificate error. So the lack of a working Internet connection doesn't seem to be causing this issue, I guess.

Are you positive that they are using the exact same FQDN, and that the loadbalancer is presenting the same certificate when they are connecting from the LAN?

Yes I am. I had one of our engineers on-site who confirmed that the FQDN is correct, and the presented certificate is 100% identical to the one being sent from our appliance.

Thanks for your reply
I haven't thought of that. I've always assumed that the certificate authorities where already trusted on most operating systems.

First of all, I hope that I've posted this in the correct forum. If not, please move it for me 

We have an appliance in our organization that accepts HTTPS connections and uses a signed SSL certificate (by Comodo). Some of our customers are connected to a large WAN network provided by an ISP (comparable to AT&T Exchange). It's a closed Internet environment. We are connected to that network as a service provider using a router and a VPN tunnel to that WAN.

The appliance has been connected to that WAN router through a switch by using its 2nd network adapter. The computers at the customers use a DNS server where the hostname of our appliance resolves to the internal IP address, so they don't connect over the public Internet. The computers being used by those customers (all are iMacs) can't connect properly to our appliance, because of a certificate error. After investigating, this appears to be a Hostname Mismatch. I've verified that the computers are connecting to the appliance by hostname, and that the hostname matches the CN in the certificate.

My next step was checking if there was something wrong with the appliance. So I've connected a laptop (a Macbook to match the OS on the customers' computers) to the same switch as the 2nd network adapter of the appliance is connected to. I was able to connect and I didn't see any certificate errors. So I think it's caused by something in the WAN.

I had a thought that it might be caused by a reverse proxy in the WAN, but the certificate that was received by these computers was the same certificate that is sent by the appliance. So that wasn't likely to be the case. The provider of the WAN network confirmed that there wasn't any proxy being used in their network.

You can find the topology in the attachment

Does anyone have a clue why this is happening? A temporary workaround is manually trusting our certificate on all those computers.