How to properly deploy a certification authority?

Question

OpenSSL

Good day! Comrades, experts, please tell me how to properly organize a certification center within the company.
Technical question:
Let's say I want to organize the following structure of certification centers:

• CompanyName Root CA - Root CA
  • CompanyName Project 1 CA - Project 1 CA
    • code design
    
    
  • CompanyName Project 2 CA
    • client, server
    
    
  • CompanyName Security CA - UD for example for VPN
    • client, server
      
    
    
  
  

The root UD exists only to create child UDs.
1. Should the root certificate (CompanyName Root CA) have links to crl and ocsp?
I looked at a bunch of root certificates from different corporations, and only a few have an indication of a link and / or to crl and ocsp. Actually the question follows:
2. If the link is specified, what will be stored at these addresses, information about revoked UD certificates?
3. Is it possible to revoke a child CA certificate?
With links to crl and ocsp in child UDs, everything is clear, links are needed there to quickly revoke client and server certificates.
An ideological question:
CompanyName Project 2 CA - Project 2 CA is responsible for:
1. Issues client certificates - to clients
2. Issues server certificates - to servers
The client having a key gets access to the server - everything is as always.
The client key, of course, is signed by CompanyName Project 2 CA, and that, in turn, CompanyName Root CA.
CompanyName Security CA - CA for example for VPN is confused by the fact that:
1. Issues client certificates - to employees
2. Issues server certificates - to vpn servers
An employee who has a key gets access to a vpn server - everything is as always.
The employee's key is signed by CompanyName Security CA, which in turn is signed by CompanyName Root CA.
Could it happen in the wild that a cunning admin who only has access to the CompanyName Security CA creates a certificate and sells it to a client who can use it to access the CompanyName Project 2 CA?
On this topic, my colleague and I had an argument. He claims he can. If suddenly the programmer implements an incorrect check inside the product, when checking the chain of certificates, the function can return a positive value, omitting the fact that the intermediate UD is not the same. He suggests creating your own ROOT CA for each project and not signing them with the company's public key.
Actually, I would like to see an opinion on this matter, how real such a scheme is.
In the course of studying the material, I came across a couple of certificates with an embedded company logo.
I even managed to add my logo to the certificate, but RFC3709 states that this is just a bauble for fun. Is there any deeper meaning to adding a logo to a certificate in practice?
Thank you.

Answer 1

Should the root certificate (CompanyName Root CA) have links to crl and ocsp?
Answer: The root self-signed certificate should not contain links to crl and ocsp
But as for any (well, almost any) subordinate certificate, it should contain. crl link. Link to ocsp - optional, according to your desire or the requirement of the information system (IS).
Accordingly, as in the certificates of subordinate CAs (Project 1, Project 2, VPN, etc.), there must be a link to crl. Not to mention the client certificates issued by the CAs of Project 1, Project 2, VPN, etc.
Link to crl in CA certificates of Project 1, Project 2, VPN, etc. will be the same and will contain the revocation list issued by the Root CA. With the help of this SOS, you can manage the certificates of subordinate CAs.
In certificates issued by UCs of Project 1, Project 2, VPN, etc. will contain a link to the crl corresponding to each specific CA, and you can manage the revocation of client certs from each subordinate CA on which the cert of this client was issued.
It is not entirely clear what the phrase "get access to the CompanyName Project 2 CA using a certificate issued by the CompanyName Security CA CA" means.
Apparently, the answer is "no" - you won't be able to access the CompanyName Project 2 CA using a certificate issued from under the CompanyName Security CA.
As for information systems that use certificates, the implementation of the function of trusting this information system to a certificate falls entirely on the shoulders of the developer of the information system and its architecture.
The easiest way to limit the use of serts issued only by the CompanyName Project 2 CA is to install the CompanyName Project 2 CA root sert on the system and check this chain. At the same time, the CompanyName Security CA cert must be absent in the IS