Hi Danny,
Thanks for verifying that "canon.us" is indeed owned by Canon (I haven't encountered that URL before and most "US" companies don't actually use the ".us" top-level-domain ... so it made me suspicious someone had registered it and was trying to redirect unsuspecting users to it.)
However... Canon still has a website problem (on Canon's end).
Fundamentally, the problem is that the SSL Certificate used has a domain name that does not match the domain of the server itself. That's not permitted ... by any web browser. It is the reason we are getting the errors (by design, the browser is *supposed* to reject your site if the browser is working correctly.)
Here's why...
When a webserver uses SSL, the server requries an SSL Certificate. It typically must be issued by a "Certificate Authority" (CA) which is trusted by the browser. (Browsers have a list of recognized CA's around the world).
E.g. if I want to run my own website, but I want to use SSL, I can contact a certificate authority (we'll pick on Verisign, they're popular) and I can purchase an SSL certificate from them. Suppose my website is called "mysite.com". Verisign will do some real-world things to validate my identity, and then they'll issue a certificate which identifies as belonging to "mysite.com" but is digitally signed (to make it tamper-evident) by their root CA (a Verisign Root CA). (Globally, there are less than about 200 well-known Root CA's that are pre-populated into every web browser to make this system work. So the list isn't so long that it would be unmanageable.)
Web browsers wont know about "mysite.com" but they WILL know about Versign's root certifiates. So as long as the SSL certificate presented to a browser is digitally signed by a "trusted" certificate authority, the browser will accept the SSL certificate as valid. Basically a trusted "root" certificate authority is "vouching" for the identity of the web server and this results in the browser's willingness to accept it.
But there's one caveat to this (and this is where the Canon site is breaking)...
The SSL certificate itself will either be host-specific or domain-specific (wildcard certificates can have a wildcard character in them to match more than one hostname). But ... whatever that host or domain name is (embedded in the certificate), IT MUST MATCH the host name (or domain name if it's a wildcard certificate) of the server which is presenting it.
You are using a link on that page that sends users to "canon.us" but it's using an encrypted connection (https://... instead of just http://...)
That means the browser expects an SSL certificate (btw, the term "SSL" is generic. The SSL protocol suite isn't actually used anymore... these days only TLS 1.2 or TLS 1.1 should be used. TLS 1.0 and all versions of SSL have been deprecated from use as no longer being adequately secure.)
Your webserver presents an SSL certificate... but the hostname in the certificate is actually a wildcard with the value of "*.budurl.com" ... and since this does not match "canon.us" the browser is rejecting it (as it is required to do).
It's possible you run more than one real server at "canon.us" (most sites run *at least* two servers to provide high availability ... but may run more). To create a highly available site, a "load balancer" is used to balance traffic between the servers. There are two major categories of load balancers... one is a "geographic load balancer" which is really a special kind of DNS server (e.g. when I request the IP address of "canon.us" it gives ME an IP address of a server ... when YOU requests the IP address of "canon.us" it may give YOU an IP address of a DIFFERENT server.) The other type is a "local" load balancer. These behave a little more like a network switch in that when I connect to an IP address (which it calls a "virtual IP" or "VIP") it actually knows there are a number of real servers (which it calls "real IP" or "RIP") behind the the load balancer.
In any case, when my browser is ultimately connected to a "real" server (eventually it will be), THAT server presents it's SSL certificate.
Suppose there are actually two datacenters and each datacenter has two servers. That's a total of four servers. It's possible that I am being load balanced to a server that has the wrong SSL certificate installed... even though other servers have a correct SSL certificate installed.
(BTW, if you haven't guessed... this is the sort of stuff I do for a living.)
The mis-configuration is DEFINITELY on your end (I can promise you that). If you can get the info routed to the appropriate people, they should be able to test EACH server (each "real" server ... regardless of load balancing) individually until they determine which one (or ones in case it's more than one) has the wrong SSL certificate installed.
No amount of trying to update web browsers on the client side will ever fix this problem. It is the intentional design of web browsers and the HTTPS protocol to not trust any cerver if it cannot present a valid SSL certificate and that the hostname of the server much match the hostname of the certificate.
Canon's server hostname (canon.us) does not match the certificate's hostname (*.budurl.com).
Tim Campbell
5D III, 5D IV, 60Da
