If you use SSL certificates on intranet sites with internal server names, they may not work from 1 November 2015.
For companies with complex infrastructures, the change may be challenging but now is the time to start getting ready. If you use SSL certificates on intranet sites with internal server names, they may not work from 1 November 2015.
For companies with complex infrastructures, the change may be challenging but now is the time to start getting ready.
Local vs. global address
Imagine you have a server on your network. It may have an IP address that is resolvable on the internet, but it’s more likely to have an address that is only valid on the local network, such as 192.168.1.1. It is also likely to have a domain name that is only resolvable on the local network, such as https://intranet.local or https://mail.
Without unique domain names that can be resolved in the context of the public internet, it is impossible for a Certification Authority to issue a trustworthy certificate.
After all, it would work for any server with that name and that creates a security risk. For this reason, the leading Certification Authorities, including Symantec, that make up the Certification Authority/Browser Forum (CA/B Forum) have decided to cease issuing certificates without a Fully Qualified Domain Name (FQDN).
Reducing your own risk
Eliminating this risk not only increases the trust in certificates but also reduces the risk of hackers obtaining certificates that validate a copycat internal address.
Currently cyber criminals are using compromised certificates to impersonate internal servers by either hacking into the corporate network, or by intercepting an intranet access request on a work device using public Wi-Fi. This in turn puts confidential company data at a high risk of exposure.
The CA/Browser Forum recommends the following possible alternatives:
But whichever route you choose, it’s important to make a plan as soon as possible so that you can continue to offer internal users secure, encrypted and authenticated websites and other services without interruption. If you are interested in a Symantec Private Certification Authority (CA) solution, please let us know or watch our webcast.
To learn more about this and other changes to the Certification Authority/Browser Forum Baseline Requirements please view this webcast.
Thanks for your post. I have request new certificate with symantec and install it on my MS Exchange enverioment, but since this day all outlook client popup alerting that " The name on the security certificate is invaled or does not match the name of the site". With this i made some investigation and i can see that the Subject Alternative Name (SAN) is missing the Internal DNS name. Accord with your post, i have some doubts:
1. My domain is like: domain.local and my Internal URL is: https://servername.local/owa, follow your post then, i must chance the the domain to something like domain.com?
2. My organization is very large, then to avoid some inturruption, exist a temporary trick to fix this alert until a change this if this is the case.
Thanks in advance for your help. I will wait your response.
Shamir, sorry we didn't catch your comment until now. If changing the name on the server is too difficult I would recommend running a Private CA from Symantec. You will be able to issue certificates off of a PRIVATE root so therefore you don't have to worry about these regulations since the SSL certificate won't work outside of your internal network.
Hi - could you clarify:
We are using the managed PKI solution. If we select "Intranet SSL" as the certificate type, then at that point why wouldn't we be able to request a SAN that is the short name of the FQDN? The "Intranet SSL" selection implies this cert is only for *internal* use, so why wouldn't Symantec be able to issue for the full requested time (not ending at 1 Nov 2015)?
When you say '...they may not work from 1 November 2015.', what is the mechanism that would prevent them from working? Is it just that you will revoke them and browsers/client apps will check certificate revokation lists or make OCSP calls?
I think, from ethical perspective, it is logical to discontinue this as,the points where,Centralized National Security Infrastructure & Corporate Internal Security Infrastructure meet,some conflicts can sometimes arise as follows considering for example,business in India:
From transparency,auditeable,legal,compliance,law enforcement & National Security perspectives (for non-classified public domain category projects being safeguarded),
For businesses/operations in India,confirmations are required by Symantec for complying with India's IT Act 2000 so that,the law is not abused/violated it in any way.
As per IT Act 2000 in India, For Cross Certification, occurring in India using ISP networks in India, the licensed CA shall have arrangement for cross certification with other licensed CAs within India, which shall be submitted to the Controller before the commencement of their operations as per rule 20. Disputes arising as a result of such arrangements shall be submitted to CCA, India for arbitration or resolution.
The arrangement for cross certification by the licensed CA with a foreign CA (e.g: Symantec) along with the application shall be submitted to CCA, India. The licensed CA shall not commence cross certification operations unless it has obtained the written or digital signature approval from CCA, India.
As per IT Act 2000 in India, there is no provision of a sub CA. All CAs must be granted license by CCA, India. In case of any dispute, the CA licensed by CCA will be answerable.
It may be challenging to align with existing legal frameworks and includes frequently contacting the CCA from Govt of India
From Technology Abuse,loss of trust,ownership & accountibility perspective,
There seem to be some bad practices & technology abuse issues associated in such setups (often more disadvantages than limited advantages) like:
Installing a fake root CA certificate on compromised systems can create phishing scams,because they allow the attacker to set up a fake domain that uses SSL/TLS and passes certificate validation steps. So, maybe this can be misused for spamming...
Man-in-the-middle (MITM) attacks can abuse certificates to intercept SSL/TLS traffic. Many software rarely complain when a server's SSL/TLS certificate has been signed by a trusted,but unexpected CA.
Man-in-the-middle (MITM) attacks in MNCs/organizations/corporations may remain hidden for many years,technology audits may not be effective. Without proper National Security/Government Approval & classified Memorandum of Understandings (MoUs) in place this could be unethical,bilaterally counter-productive & in the long run and can introduce net neutrality violation.
e.g: When connecting to some HTTPS website, the server’s certificate is being signed by an entity other than that website.
Also, consider an internally hacked type network where,DNS forward,reverse lookups are not working properly at all times & authenticity of web server cannot be determined.
In such cases, the traffic can be captured illegitimately. Malware installed illegitimate certificates might also become possible.
Maybe it would be of little help to provide internal security in a hostage situation where the secured ship itself is lost/ownership gets transferred/snatched to/by maybe the underworld/digital mafia/sleeper cells/HRs capable of waging 3rd world war & in control of corporate zombie army of innocent employees.
Situations & consequences could be uncontrollable like,if a malicious Browser Helper Object (BHO) installs a fake Verisign cert as a Trusted Root Certificate Authority after infecting the system to eliminate security warnings.
Or if a spyware acts as a local proxy for SSL/TLS traffic and install rogue certificate to conceal this behavior.
does this apply for self signed certificates as well?