Verifying and trusting some root certificate of an unusual CA might present a problem. In fact, to download the root cert of this CA from its corresponding website one should verify and trust first the TLS cert presented by that website. Meaning trusting the root cert of the CA signing the website’s TLS cert. It seems like a chicken-and-the-egg problem. How could one solve that ?
Already good answers. I will focus mine solely on the chicken and egg problem.
Egg: You are trying to validate a certificate, but the cert chains to a root that you have never seen before.
Chicken: To decide whether you should trust this CA, you look at who issued the root cert, but the issuer of a root CA cert is always ... itself, so we're back to the egg scenario.
Hence the name "root CA certs" for "root of trust". If you trust the root, then you trust the entire tree. If you don't trust the root, then you don't trust the entire tree. But how to determine if a root CA is trustworthy?
There is no automated way to determine whether a root CA is trustworthy, and that's kinda the point. Basically, you need to get to know the organization (ie the humans) who run that CA and decide whether they are trustworthy and doing their jobs properly. As an example, let's look at Mozilla's process for deciding whether a CA should be included in the truststores of Firefox and other products.
First, see: Mozilla's CA Certificate Program which overviews every detail of their process around the root trust store (huge kudos to them for making all this public!).
Next, we dive a little deeper into their CA Application Process. As you can see, there is a very rigorous and time-consuming process by which Mozilla determines whether a CA is "good enough" to be included in the Mozilla trust store.
Bottom-line: there is no over-the-internet way to determine whether a root CA is trustworthy (I guess you could look them up on a forum or something, but how do you know if you should trust those people? See: chicken-egg). You need to first have in-real-life trust in the people running the CA. The other answers detail the risks of adding a malicious root cert, so I won't go over that.
Let's assume the CA you're thinking of adding is run by your company / school / friend: you believe them to be honest (not issuing fake certs to bad-guys), and you think they are have good security practices to prevent their CA from being hacked (highly unlikely unless, at a minimum, they have spent thousands of dollars on Hardware Security Modules to store their CA private key, and firewalls to protect their admin interface), then go ahead and add it.
Otherwise, if this is some root cert that you stumbled across on the internet, you would need to reach out to the organization behind the CA by phone and go through your own version of the Mozilla check-list (which probably involves several months of your time and several plane tickets on both your part and the CA's part).
Bottom-bottom-line: Unless the root CA is your company / school and you are literally required to add it for your computer to work, *then don't*. Mozilla / Google / Microsoft / Apple, etc have very rigorous processes for vetting CAs, so if that CA was not included, there's probably a reason.
You should never ever trust a new root CA unless you really (and I mean really really) believe that it is fully trustable. Even then you should get the CA certificate in a trusted way, i.e. definitely not by downloading it from a site which certificate is issued by the same yet untrusted CA.
The main problem with explicitly added root CA is that any explicitly added CA is automatically trusted to issue a certificate for any domain. This means even if example.com has usually a certificate signed by InnocentCA the browser will also accept without any notice a certificate signed by MaliciousCA, if you have added MaliciousCA as trusted CA. This makes man in the middle attacks or other kinds of domain impersonation by MaliciousCA easy.
Even certificate pinning (built-in or with HPKP) will not help since pinning is disabled in browsers if the certificate is signed by an explicitly added CA, to make legal SSL interception as used in enterprise firewalls and many desktop antivirus possible.
First, you have to consider why this organization believes they should be issuing their own root CA and distributing it to you.
Does this certificate belong to your own organization? Does your organization manage their own PKI and issue their own internal certificates, for internal boxes to communicate with each other? This is a common scenario in industry or other larger organizations, and is a perfectly legitimate reason to internally distribute certificates from an internal server to internal clients. At that point you're discussing obtaining the certificates via a private network, where your organization presumably has security and controls on the distribution of root certificates. Trusting such a server and certificate should pose little problem to you as a member of the organization.
If this is from some external site (perhaps one that doesn't understand certificate authorities and built their own PKI instead of paying for a certificate,) and is now asking their clients to trust their root CA, then no. There is no reason to trust their certificate as a root CA. So if this is a connection to a vendor's site, ask them to provision their server with a properly signed certificate from a well-known trusted root CA. You're paying them for the service, not to introduce security vulnerabilities. There is no reason they should put your systems at risk to use theirs.
If they are unwilling or unable to cooperate, you have to question their understanding of PKI and perhaps their competence in security in general. Consider finding an alternate vendor who poses less of a risk. If no alternative is possible and you have not choice but to use their services, you should act to minimize the risk to your organization. For example, you could stand up your own proxy server that trusts their certificate and would connect to their server; your clients would only use and trust your proxy to access the vendor's services. That would limit your risk to a single proxy system.
If you do have to accept their root CA on your client systems, be sure to import their certificate granting it only the minimum privileges. When importing a root CA certificate, most systems will prompt you with a series of check-boxes: "trust this certificate to identify web sites?" "trust this certificate for digital signatures?" "trust this certificate for software updates?" Be sure to only grant it the appropriate level of trust.
It's all to do with trust.
The root CA certificates of many come prelaoded within operating systems and some browsers. You may not even know this, but that's because these manufacturers have trusted them on your behalf (you can always remove any). If the CA site you are visiting does not have the root installed then you will receive an error - at this point you either trust the certificate and proceed so you can get the root to download, or you stop.
If you download and install a root CA then you are solely taking that trust on. If you do not trust the CA then do not install it's root certificate. If you are unsure whether to trust the CA then asking around is a good start, but that said if the root is not installed on other client machines then they will get a certificate error when they try to use the client certificate in the chain anyway. This therefore in your example means that you either chose to trust the error to proceed downloading the root certificate for that site, or you did not - as you would have received an error without the root certificate in the first place.
You can copy the thumbprint(or fingerprint whatever) of the Root CA's certificate, then google it, if it is authentic, it will show results of the CA's name exactly as yours.
For detail, assume you are using Chrome browser, you enter your target https site to verify,