How can I create and use the cross signing certificate?

Question

: I'm trying to create an environment with cross-signed CAs, and verify a certificate issued against one of the CAs, all using openssl. The best I got so far is getting openssl into an endless loop while verifying (the loop is terminated at level 100). I've published all of the certs I created. Now, there are a number of assumptions that I'm making, and largely based on this Oasis document to build the model. Here are my assumptions:

There should be 4 certificates, self-signed from authorities #1 and #2, and cross-signed, where authority #1 is signed by authority #2 and vice versa.

There are only 2 actual subjects (DNs) used (the same subject used by an authority for self-signed is what it has signed by the other authority, albeit in a different cert).

All 4 certificates should be part of the end-user trust.

The keys used by the same authority, for both self- and cross- signed certificates should be the same

AKI should not be used (Maybe "shouldn't" is too strong a word, but not using it shouldn't hurt. Because of the same keys rule, it shouldn't matter though)

I tried setting CA:TRUE for cross-signed certs, with the same result.

My understanding of cross signing is that it gives the verification process alternative paths. Considering that I see an openssl loop, it seems to be picking cross-signed certificates every time. So the crux of the question is - what would make the verification process to favour the self-signed certificate over the cross-signed one, considering both have the same subject. Here is a test leaf certificate, I can't make openssl verify to verify it successfully.

[vps@druid]~/ws/EF/pki3$  openssl verify -verbose -CAfile cas.pem cert.pem 
cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 2 at 100 depth lookup:unable to get issuer certificate

Andrew Jenkins · Accepted Answer

OK, this is the best that I came up with so far. The problem with depth processing, I believe, is just OpenSSL's. It's not good that it can't build proper paths. RFC-5280, Sec 6.1 says: A certificate MUST NOT appear more than once in a prospective certification path. OpenSSL probably violates that. However, I have to say that I don't quite see an explanation in RFC-5280 on how to build paths, except for its Sec 3.2; there are suggestion that paths must end with a single self-signed CA at the end of each chain (that, however, contradicts with statements that verification chain should not have trust anchors, but trust anchors may contain intermediate certs, which makes the post-chain side contain multiple certificates, where OpenSSL ends up with infinite loop). Either way, I don't agree with what OpenSSL is doing.I also should say that what I was talking about is not just cross signing certificates, but mutually cross signed certificates. The obvious difference is that normal cross-signed don't create such a circular dependency, and is achieved by having a trust anchor from one CA that is signed by another CA (from the perspective of verifier, it's the same case as a trusted intermediary, AFAIU). The way to make it work with OpenSSL, is by not adding cross signed certs into the trust list, but provide them as part of the intermediate certificates produced by the key holder.If I put all self-signed in trust.pem, all cross-certs in untrust.pem, then verifier works, albeit spews intermediate errors (which makes sense as not all trees build/verify successfully): Here is with both roots present: $ openssl verify -verbose -CAfile trust.pem -untrusted nontrust.pem host1/cert.pem host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1 error 24 at 1 depth lookup:invalid CA certificate C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2error 24 at 2 depth lookup:invalid CA certificate OK Here is with only one or another root present:$ openssl verify -verbose -CAfile ca1/ca1.pem -untrusted non trust.pem host1/cert.pem host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1 error 24 at 1 depth lookup:invalid CA certificate C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2 error 24 at 2 depth lookup:invalid CA certificateOK $ openssl verify -verbose -CAfile ca2/ca 2.pem -untrusted non trust.pem host1/cert.pem host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1 error 24 at 1 depth lookup:invalid CA certificate OKWhich shows the coolest part of the cross signing that we can nuke a CA, and still have original certs working. HOWEVER RFC-5246, Sec. 7.4.2 that documents TLS 1.2 says that the server has only one chain to present to the client (and vice versa). If the cross signed certs can not be part of the trust store, then the client has to provide multiple chains in order for the verifying side that there are options. So, yes, it works in theory, but not with SSL (it may work with other verification protocols, I didn't check), at least in OpenSSL implementation of it.

Ranjana Admin · Answer

Creating and using a cross-signing certificate involves several steps, including creating the certificate, signing it with an existing certificate, and then using it within a Public Key Infrastructure (PKI). Here’s a step-by-step guide:

Step 1: Create a New Certificate

You can use OpenSSL to create a new certificate. Here’s an example of how to generate a new certificate and key:

1. Generate a private key:

  openssl genpkey -algorithm RSA -out new_private_key.pem -aes256

2. Generate a Certificate Signing Request (CSR):

  openssl req -new -key new_private_key.pem -out new_csr.csr

Step 2: Sign the New Certificate with an Existing CA

You need an existing Certificate Authority (CA) to cross-sign your new certificate. Here’s how you can do it:

1. Sign the CSR with the existing CA:

  openssl x509 -req -in new_csr.csr -CA existing_ca_cert.pem -CAkey existing_ca_key.pem -CAcreateserial -out new_cert.pem -days 365 -sha256

existing_ca_cert.pem: The certificate of the existing CA.
existing_ca_key.pem: The private key of the existing CA.
-CAcreateserial: Creates a serial number for the certificate if it doesn’t already exist

Step 3: Verify the Cross-Signed Certificate

Ensure that the new certificate has been signed correctly by the existing CA:

  openssl verify -CAfile existing_ca_cert.pem new_cert.pem

Step 4: Use the Cross-Signed Certificate

Once you have the cross-signed certificate, you can use it in your applications. Here’s an example for a web server (e.g., Apache or Nginx)

1.Apache Configuration:

Place new_cert.pem and new_private_key.pem in a directory on your server.

  Edit the Apache configuration file &#40;e.g., httpd.conf or ssl.conf&#41;:

SSLCertificateFile /path/to/new_cert.pem
SSLCertificateKeyFile /path/to/new_private_key.pem
SSLCertificateChainFile /path/to/existing_ca_cert.pem

Nginx Configuration:

Place new_cert.pem and new_private_key.pem in a directory on your server.
Edit the Nginx configuration file (e.g., nginx.conf or a specific site configuration file):

  server {    listen 443 ssl;    ssl_certificate /path/to/new_cert.pem;    ssl_certificate_key /path/to/new_private_key.pem;    ssl_trusted_certificate /path/to/existing_ca_cert.pem;    ...}

Step 5: Distribute the Cross-Signed Certificate

Ensure that the certificate is available to all parties that need to trust it. This might involve distributing it to clients, installing it on servers, or providing it as part of a software package.

Summary

Generate a new private key and CSR.
Sign the CSR with an existing CA to create a cross-signed certificate.
Verify the cross-signed certificate.
Configure servers/applications to use the cross-signed certificate.
Distribute the certificate as needed.

This process helps to establish trust across different systems by leveraging the trust established by an existing CA.

How can I create and use the cross signing certificate?

About this question

Your answer

2 Answers

More Cyber Security discussions

Learn & Explore

Cyber Security Tutorials

Cyber Security Interview Q&A

Latest Cyber Security Blogs

Want answers to more Cyber Security questions?

Stay in the loop — it’s free

You’re on the list!