Intermediate CA authenticity in an embedded device

Question

My company are using an offline embedded device, that must encrypt connections to its client (a PC connected with USB).
We have chosen to use TLS with both PC and device authentification to encrypt messages, and use certificates to secure the system.
So the device needs to send CSR and receives its certificates to authenticate and secure connection.
Also, It needs to store the root certificate of my company.
These certificates will not be downloaded directly from the internet, the client PC will act as a proxy and relay them to the device.
My question is how I can validate that the intermediate CA is authentic (that was created only by my company).

My guess was to use the Organisation or Common Name of the CA that can be identified with the company name.
And use the CA certificates chain to validate that the CA is not self-signed.

But could it be possible to create a CA cert with valid chain certs and with the same name as my company in Organisation or CN field?
For example, an intermediate CA cert that has the same common name but different parent authorities (Verisign, Let's Encrypt...)
Are there other ways to authenticate intermediate CA?

Thank you for reading this message, and for your answers.

Answer 1

Being a CA means that there is a great deal of trust placed in them. The global CAs present in your browser and OS all follow the CA/Browser Forum rules regarding who they will issue certificates to, how they validate clients, and what kinds of permissions they'll allow on certificates. Very specifically, a global CA will not issue anyone a certificate with the KeyUsage field permitting either keyCertSign or cRLSign. This means you cannot create your own intermediate CA signed by Verisign, because that would allow you to forge certificates for anyone on the planet. Verisign would lose their global CA status quickly if they issued signing certificates to their clients.

To use client certificates the way you're describing, your organization has to have your own private PKI and distribute your own organization's trusted CA root certificate to all participants. Your PKI is then free do do whatever you need, such as issue an intermediate CA a certificate that can sign client certificate requests. But just like trusting the global CAs, you must place a lot of trust in your private PKI, espeically to not sign inappropriate requests.

Larger organizations that run their own private PKI will often use a certificate request management system that serves as a protective front end to their signing CAs. This system's job is to authenticate that certificate signing requests (CSRs) come only from authorized consumers; it ensures that incoming CSRs don't request inappropriate permissions; that CSRs all follow corporate policies and standards for every field; and they'll keep an inventory of all issued certificates (which can come in handy if you need to know when certificates in your organization are about to expire.)

Your PKI team would rely on such a system to not issue Subordinate CA signing permissions to anyone but the PKI team. This would prevent a client from generating a rogue intermediate CA. And that's what prevents the scenario you describe.