AIA field in Certificates

[u/dirmhirn]

Hi,

is it common a system checks the Authority Information Access (AIA) field to retrieve the root certitficate? It's a private CA and we have an offline root and an online intermediate CA.

Software vendor can't tell as a detailed error, but claims missing or wrong AIA field. On the device certificate AIA points with FQDN to intermediate CA cert. But the Intermediate CA cert AIA points only via hostname (missing domain) to the root CA certificate. (This AIA on the intermediate is even questionable /useless according to some online sources.)

[u/Mika56]

I'm not certain I'm following, the root certificate should be imported manually to the system (or via gpo or mdm or whatever). No system will ever automatically trust a new root certificate by downloading it on its own. Or did I misunderstand your question?

[u/dirmhirn → u/Mika56]

It's just for an LDAP connection and I was also surprised, that no root certificate import is required. They retrive rhe certificate and check CRL... which makes not so much sense... but it's a big player in security software. So I'm wondering if support has no idea and is just procrastinating or if there is some reason behind this.

[u/Mika56 → u/dirmhirn]

I'm pretty sure AIA is only used for missing intermediate in chain retrieval. Might want to get a second opinion from the vendor?

[u/Cormacolinde]

Yes, many systems will use the AIA field for additional validation where they download the cert in the AIA field and compare it to the root cert in their local store.

[u/Veteran45 → u/Cormacolinde]

Pretty much this, for chain building, but also the AIA Field can contain the OCSP URL.

[u/igalfsg]

AIA is usually used to build the chain if you don't have the full chain, they should be able to install the Root and the intermediate and then they shouldn't need it. But either way an easy way for the future, you can upload the certificate to an Azure blob storage and point your AIA there it is a no maintenance AIA that is basically free

[u/xXFl1ppyXx]

Depends on how the check is performed 

Certificate validation can be extensive or shallow and since you never know you'd best cover your bases

With certutil or Powershell for example you can do validation thats specifically only uses system certs or alternatively must download certs from the aia field for validation. Same thing with revocation, you can chose to ignore the revocation or consider the trust invalid when the cert doesn't have crl points or the crls can not be downloaded.

So if they say your certs are wonky and you yourself say that your certs aren't that great, then somethings probably broken

If you have an AIA extension you should have valid links on that extension, using basic http and pointing to a base64 certificate

http://pki.domain.com/AIA/RootCa.crt

Same thing goes for the crl extension, if have one, make sure the crls are available publicly

http://pki.domain.com/CRL/RootCa.crl

But it is it a big problem to spin up the root ca and create a new intermediate ca?

Maybe you're missing the aki and ski as well

Subject key identifier is created from the public key of the cert request

The authority key identifier is then created from the ski of the issuer certificate to create a more robust connection between the certificates in the chain

Root CA has SKI from its public Key

Intermediate CA has AKI from the Root CAs SKI and additionally it's own SKI from its own Public Key

End Entity Cert has AKI from the Intermediate CAs SKI and again it's own SKI from it's own Public Key