08-07-2018 07:47 PM - edited 08-07-2018 07:49 PM
I noticed that if you go to https://community.usa.canon.com you get a page with several links... one of which is the "Canon Forum".
But if you pick that link, it tries to go to: https://canon.us/YSGl
(Note: The REAL Canon forums are here: https://community.usa.canon.com/t5/Canon-Forum/ct-p/Canon_Forum )
I'm pretty sure that's not a valid Canon USA url. If I check it, my browser gives a security warning not to trust the site (becuase the certificate doesn't match the URL). If I inspect the certificate, I get this:
I'm reasonably confident that Canon USA isn't running any part of their website using that certificate, nor under the domain name of "canon.us".
You may want to have your webmaster check that and do some security scans on your web servers.
08-07-2018 08:00 PM
Hello Tcampbell and thanks for bringing this to our attention. We want to look into this and investigate further and want to confirm the short link you are referring to is from the "Canon Forum" graphic on the left just under the header image?
We want to be sure before we escalate up to the "Internet Fixing People", as from your description it looks like a redirect URL but we are not able to reproduce the issue.
Any confirmation would be helpful!
08-08-2018 12:44 AM - edited 08-08-2018 12:47 AM
08-08-2018 09:03 AM
Thanks for the additional information, Rick!
The "canon.us" URL is one officially used by Canon USA and we currently use it as a way to maintain our corporate branding while providing compact links. The links bearing that URL are legitimate.
We've attempted to recreate the issue on our end and have encountered no problems. You may want to make sure you're using the most up-to-date version of your web browser to ensure full functionality.
Please let us know if you continue to experience any difficulties. Thanks for posting!
08-08-2018 10:29 AM
Same results and behavior in Chrome, Edge, IE and FF. I'm running the latest versions of each.. While the site has not been hacked, there is a problem with the certificate. Whether Canon wants to take any action on this is up to the team who manages your website.
08-08-2018 11:36 AM
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.)
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).
08-08-2018 07:45 PM
That began Monday, I believe. There are issues with the shortcuts to forums at the top of the home page, too. I was getting logged out if you click on one since late last week.
08-15-2018 10:22 AM
BTW, looks like the URL's have been updated to go to the correct locations without giving the certificate warnings.
I've been checking this for a few days (just in case it was a matter random probability that could send me to a working vs. non-working server). It has been behaving correctly each time I check ... so hopefully that means the issue has been resolved.
08-25-2018 01:30 PM
I am still getting logged out occasionally when I click on one of the shortcut links to forums across the top of the screen. I just got logged out when I was in the Rebel forum, and clicked the Cinema EOS link.
08-25-2018 01:48 PM
If you haven't already done so, you may want to clear your browser cache to ensure any old cookies or outdated information aren't getting in your way.
Hope that helps!