Do you have any intranet sites with a domain name like https://intranet.local? Or a mail server with an address like https://mail? These kind of internal-only domain names are very common but they pose a real problem.
SSL certificates on an intranet
Symantec and other Certification Authorities (CAs) and browser vendors, that make up the CA/Browser Forum have decided to stop issuing SSL certificates chained to a public root which cannot be resolved in the context of the public internet.
This means that domain names need to be globally unique and not just unique on your network. So if you have a .local domain that you use internally, you will soon no longer be able to purchase a validated SSL certificate for this name.
With the emergence of new gTLDs, such as .london, and the likelihood that many of the very common names used to identify server domains internally will be purchased and used by commercial organisations (names such as .red and .home have already been applied for and more will surely follow and unless you specifically own these gTLDs you will no longer be able to purchase a validated SSL certificate for them).
Although this will improve security it creates challenges for organisations with servers that use these internal-only domain names or reserved IP addresses.
Getting ready for the change
Alternatives include switching to fully-qualified domain names, using self-signed certificates or setting up a private certification authority (CA) to authenticate internal domain names.
For many companies, this last option – a private CA – is a smart way to get ready for the changeover as it requires the least change to existing systems and the lowest level of risk.
The Symantec option
Symantec recently announced its Private Certification Authority solution. It lets you avoid the risks and hidden costs of self-signed certificates and the switching costs of deploying fully-qualified internet domain names across your entire intranet.
Using Symantec’s bulletproof infrastructure, it covers requirements ranging from single-domain intranet SSL certificates, wildcard certificates up to self-signed CAs. It provides a hosted private SSL certificate hierarchy with end-entity certificates specifically built to secure your internal communications.
Using the Managed PKI for SSL console assists in simplifying SSL management by letting you manage public and private certificates in one control center. This helps you avoid the risk of unexpected expiries and issue new certificates as required. So if you have internal servers that use deprecated domain names then you need to consider a solution sooner rather than later.
Well, that is needed if you want to. This is what people want to do with website for more security as I guess.
For businesses/operations in India, Can you confirm, Symantec is complying with India's IT Act 2000 and is not abusing/violating 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.
Has Symantec followed these rules fully and is it frequently contacting the CCA from Govt of India?
Please provide your views on the following from compliance,legal and law enforcement perspectives:
There seem to be some bad practices and 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.
Can this be misused for spamming?
Man-in-the-middle (MITM) attacks abuses certificates to intercept SSL/TLS traffic. Many software rarely complains when a server's SSL/TLS certificate has been signed by a trusted, but unexpected CA.
Man-in-the-middle (MITM) attacks in corporations without proper National Security/Government Approval and classified Memorandum of Understandings (MoUs) in place could be unethical,bilaterally counter-productive and 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, DNS forward and reverse lookups are not working properly.
In such cases, the traffic can be captured illegitimately. Malware installed illegitimate certificates might also become possible.
Is this quite similar to the following situations?
What could be the consequences 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.