chris2511
Creating signed certificate under CA with same name
Hi! Thanks for your awesome software!
I came across an interesting thing when attempting to create a subordinate CA in a 3-tier PKI structure. I didn't realize it at the time, but the pathlen field got set to 0. It looks like xca still allows a subordinate CA to be created under the certificate where pathlen=0. Is this by design? If it's meant to be like this, can there be a visual indication within xca that the certificate won't pass certificate chain validation checks?
Now that I've seen this, I'm going through an exercise to create a new chain (underneath the Root) without the pathlen restrictions.
As you can see, the Internal Name/commonName are the same (although serial numbers are different). When I attempt to use the menu "Transform --> Similar Certificate" on the Firepower CA certificate, and change the "Use this certificate for signing", I don't know which CA I'm selecting (given that they both have the same names) and no matter which one I pick, it still seems to only sign with the first CA in the drop-down list and not the second.
Is it possible to include the serial numbers in parenthesis/square brackets so that one can see which CA should be signing the certificate if they have the same name?
Thanks again! Nolan
What is also interesting is that if I delete the second "Subordinate CA - RSA - 2048" (the one that's highlighted which has the "Firepower CA - 2048" underneath it), it moves it up to show the "Firepower CA - 2048" is now a child of the first "Subordinate CA - RSA - 2048" certificate authority. It doesn't look like it's building the chain correctly to create the appropriate order.
Hope that makes sense?
Let me know if you have any questions. Nolan
Hi, let me try to answer your observations one by one
- Indistinguishable CAs: It's up to you to edit the internal name of the CA at any time. It is not part of the certificate.
- Issuing with pathlen=0: XCA does not check this extensions, it only looks at the CA=true flag -> Feature to warn before issuing and mark issued certificates, that won't pass chain verification
- Wrong assignment of issued certificates and reassignment after deleting the issuing CA: It's not a bug, it's a feature. If there are two certificates with the same subject and same private key, both are potential issuers. In this case XCA picks the one which is longer validity as issuing CA. If you remove it, XCA picks the other one. If you remove that one, too, the issued certificates will be rerouted to the top-level.
Thank you for being more methodical in summarizing my posts :-) I would like that feature check for pathlen=0.
Thank you for clarifying that information around how xca determines the path for a certificate (this is good information to work with).
I think my query is around the path building. How about this scenario: There are 2 certificate authorities (CA1 and CA2) which both have the same name but different expiry dates, CA1 has certificate (Cert1) issued underneath it
Now, CA1 gets deleted, the certificate Cert1 shouldn't be assigned to CA2 because from a chain-building perspective, CA2 never issued Cert1. Cert1 should be an "orphan" certificate.
If that's the intended outcome, then ok. I'll have to keep that in mind with this scenario.
Thanks again for your feedback! I really appreciate it.
Nolan
The difference is the private key. If both CA certificates use different keys, the behavior is exactly as expected by you. Actually the target software also only recognizes the CA by searching the list of trusted certificates with "my:issuer == ca:subject" and then checks, whether the public key inside a matching CA certificate signed "me". Then the client does all the verifications with pathlen,key-usage, basic constraints, name-constraints and so on
Thanks for the response. How difficult would it be to have the xca software instead match the Authority Key Index (AKI) and Subject Key Index (SKI) values to build the visual chain of authority? Feature request? :-)