0

Let's say I have rootCA.crt, intermediateCA.crt and leaf.crt. I used openssl to veriy leaf.crt:

cat rootCA.crt intermediate.crt > chain.crt
openssl verify -CAfile chain.crt leaf.crt

and it said everything was OK.

I later added rootCA.crt as Trusted Root and intermediateCA.crt as Intermediate Root. Opening either of them in Windows shows that they are trusted, for intermedaiteCA.crt it even shows rootCA.crt as parent. But when I open leaf.crt it says that This certificate has an invalid digital signature. I tried to add it to certificate store using Automatically select the certificate store based on type of certificate, but even then it is still not trusted and Windows claims that it has invalid signature.

leaf.crt is issued for our local gitlab instance (but not as cert for https, it has Key Usage = Digital Signature, Key Encipherment, Data Encipherment (b0)). The only thing I can think of is that its CN is not in SAN field. It has CN = zs.node.broker-GITLAB while SAN contains localhost, 127.0.0.1, machine's IP and DNS name gitlab.our-local-domain. CN is the way it is because we issue certificates for various devices and it was decided that this server will use one of these certificates. Unfortunately I cannot create ad-hoc certificate to check it and that is why I'd like to verify as much as I can before starting painful process of issuing another certificate.

Except for that (CN not in SAN for leaf.crt) all certificates are pretty standard I think. They are all 2048 bit, signature algorithm is sha256RSA. rootCA has Key Usage = Certificate Signing, Off-line CRL Signing, CRL Signing (06), Basic Constraints = (Subject Type=CA, Path Length Constraint=None). (Both with little yellow triangle with exclamation mark in Windows certificate display - I don't know why really). intermediateCA has Key Usage = Certificate Signing, Off-line CRL Signing, CRL Signing (06), Basic Constraints = (Subject Type=CA, Path Length Constraint=0).

Do I have some serious issues with my certificates or is it something simple?

Improve this question
3
  • The little yellow triangle with exclamation mark (sounds like it should be a Unicode character, but isn't) indicates extension marked critical; BC always is, and KU (if present) usually is. Are you asserting your leaf KU prevents https (or other TLS) -- it doesn't -- or just that you don't use this cert for https/TLS? That said, openssl verify by default doesn't check self-signature on root while Windows does, but that doesn't explain a difference on leaf. You might try adding -x509_strict and see if it catches anything, although I think signature check shouldn't need it.
    – dave_thompson_085
    Oct 26, 2022 at 1:34
  • I'm just stating that I'm not using this certificate for https. They are used for TLS (which I think is less strict than https, AFAIR TLS does not verify CN/SAN but there is a high chance I am wrong) - I don't know if they include all proper Key usages for this - but this is outside of my current problem. Running openssl verify -x509_strict -CAfile chain.crt leaf.crt passes without any issues.
    – Jędrzej Dudkiewicz
    Oct 26, 2022 at 7:59
  • TLS is used for many things, some of which (including https) check hostname and some of which don't. See rfc 6125 for some important cases, but it's not exhaustive. If -x509_strict doesn't catch anything I'm mystified -- unless you can post actual certs for people (including me) to try, and you would probably need to generate a nonsensitive test cert for that which conflicts with your goal of not generating a cert :-(
    – dave_thompson_085
    Oct 27, 2022 at 4:47

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .