Best way to manage large trusted cert store?

[Chris Bertagnolli]

As part of using the CA API Gateway we are required to maintain the Root CA and Intermediates based on public and Federal PKI trust management. This will be to support certificate authentication via registered credentials (i.e., must be from a trusted known chain with full path validation). 

 

That'll be ~40 Root CAs and over 100 Intermediates.

 

In our Windows Servers this is not an issue since GPO handles it across all of them. However, we are trying to determine best way to handle the updates in the CA API Gateway.

 

I'd like to automate it if possible via an API or some way to write them directly to the trust store or whatever would work best.

 

The certificates themselves we receive in PEM format or via our LDAP directory where they are also hosted and can be queried. 

 

Is there any advice or personal experience that someone could share with us to manage these? Would RESTMan be able to handle this if we had a job that ran to add/modify and appropriately flag the certs (Trust Anchor, perfom revocation check, so on)?

[Seiji Moriyama]

Hello,

 

Do you have so many backend HTTPS servers which have server ceritificates issued by a variety of Certificate Authorities?
In the case of web browsers, I understand that they have to have a lot of trusted root and intemediate certificates but I think the backend servers of the CA API Gateway are almost fixed and not so many. (Maybe I'm merely not familiar with such usecases.)

 

How about storing your certificates in a PKCS12 keystore file or a Java keystore file, and importing it with the Policy Manager? (Manage Certificates task)
Unfortunately, it seems the Trust Anchor and Revocation checking have to be configured manually in the Policy Manager.

 

Best regards,
Seiji

[Chris Bertagnolli]

It's not the routing I'm concerned so much with since that will be more fixed list that even manually shouldn't be too bad.

 

My concern is more the Client Certificate Authentication. We accept certificate authentication from numerous possible chains, so long as it chains to a trusted root then it can be used to authenticate on the front-end.

 

So basically:  Trusted Issuer --- TLS client cert auth ---> API Gateway (validates OID, chain, revocation) --- Proxy --> App Back-end

 

To have the trust established for the client cert auth we have to walk the full path up to the root. This means maintaining the roots and the intermediates.

 

Manually managing that many certificates can be a pain doing it via GUI. I was hoping some automated way to handle it since there are some months we have to make quite a few updates and has to be quick so that once a new CA/Intermediate is identified then we have to start accepting those certs as quick as possible so that authentication succeeds.

 

It wouldn't be end of the world to do it via the GUI if we can import the full PEM or JKS file, just the more we can automate these little time consuming operational tasks the better . Rather the admins spend time on enhancements than clicking through buttons for certs.

[Chris Bertagnolli]

Trying out a PEM with all the intermediates, but this doesn't work because it only extracts the first certificate and not all of them. Same with a p7b file which also only imports the first one only. JKS seems to allow importing multiple at once though, so was able to get Roots installed using a JKS and setting them to "trust anchor" but then had to go into each one and manually disable revocation checking.

 

I'd still rather automate this and having to manually go into each root / intermediate to set the options on them after import is really time consuming. It's also prone to errors if someone misses checking a box like disabling revocation checking on a Root CA.

[Chris Bertagnolli]

From the REST Man docs, it seems like maybe we can do it there? Then I downloaded the template which has parameters to indicate usage, revocation checking, root or not, etc.

 

<l7:Property key="revocationCheckingEnabled">

<l7:BooleanValue>true</l7:BooleanValue>

Creates or Updates an existing certificate. If a certificate with the given ID does not exist one will be created, otherwise the existing one will be updated.

[Stephen Hughes]

Chris,

 

Were you able to get the solution you were looking for?

 

Sincerely,

 

Stephen Hughes

Broadcom Support

[Chris Bertagnolli]

We have not implemented it yet, but will try going down the restman api path once resources are available to setup the scripts.

 

Hoping that works since that'd be pretty easy to then feed in new certs whenever they change.

[Zhijun He]

Yes, I believe /restman should be good for your use case.

I done another use case to load the certificate from saml meta file into gateway, not the same use case, but similar.

here is my payload which could save your time,

<l7:TrustedCertificate xmlns:l7="http://ns.l7tech.com/2010/04/gateway-management">
  <l7:Name>spcert</l7:Name>
  <l7:CertificateData>
    <l7:Encoded>${cert.results[0]}</l7:Encoded>
  </l7:CertificateData>
  <l7:Properties>
    <l7:Property key="revocationCheckingEnabled">
      <l7:BooleanValue>true</l7:BooleanValue>
    </l7:Property>
    <l7:Property key="trustAnchor">
      <l7:BooleanValue>true</l7:BooleanValue>
    </l7:Property>
    <l7:Property key="trustedAsSamlAttestingEntity">
      <l7:BooleanValue>true</l7:BooleanValue>
    </l7:Property>
    <l7:Property key="trustedAsSamlIssuer">
      <l7:BooleanValue>true</l7:BooleanValue>
    </l7:Property>
    <l7:Property key="trustedForSigningClientCerts">
      <l7:BooleanValue>true</l7:BooleanValue>
    </l7:Property>
    <l7:Property key="trustedForSigningServerCerts">
      <l7:BooleanValue>true</l7:BooleanValue>
    </l7:Property>
    <l7:Property key="trustedForSsl">
      <l7:BooleanValue>true</l7:BooleanValue>
    </l7:Property>
    <l7:Property key="verifyHostname">
      <l7:BooleanValue>false</l7:BooleanValue>
    </l7:Property>
  </l7:Properties>
</l7:TrustedCertificate>

 

${cert.results[0]} is the base64 encoded X509 cert data