0

I am looking to expand trust within our application by setting up mutual TLS between the customer service and our service. I am trying to wrap my head around this stuff as I am kinda new to this tech so would like to confirm my approach.

I am thinking of asking the customer for their Domain-validated certificate. I will then cross-sign it with our own intermediate CA (AWS private CA) and generate a leaf certificate which they will use for requests.

On the handshake with our server I want validate that they are a company/domain allowed to interact with our services (validate their DV cert). Also, since I cross sign with our CA I can revoke their access if needed. So basically I validate those two things.

Is this best practice for this sort of thing? Will the customer need to provide me with a new certificate every year when it expires? Will I have any problems cross signing their DV cert with my intermediate CA?

Extra information:

I want there to be a real-time set-up of a trusted encrypted session. So I want the client (which will be the customer server) to send a certificate (which we provide) to our service.

I'm trying to build a trust network in which I can onboard new users and ensure they are trusted entities (hence the DV cert part)

Maybe I don't have my own private CA and, instead, use a commercial CA instead.

Improve this question

2 Answers 2

Reset to default
0

A certificate can only have a single signature, which means that one cannot add just another trust chain at this level as proposed here. Cross-signing is instead to have multiple issuer certificates which share the same public key (and thus same private key), which allows for different trust chains. This is usually done when transitioning trust from one root CA to another. This is thus not the kind of use case described here and you don't have access to the key pair of the original issuer CA anyway in order to cross-sign with your own certificate using this key.

Given that full control over the certificate is expected here (including revoking) it looks like the correct way is to let your own root CA simply issue the client certificates for the customers and ship these to the customer for use. If the customer instead insists on using its own certificate one could pin to these certificates or the public key inside it.

Improve this answer
2
  • It's more we would insist they also send their DV ( or OV ) Cert so we can add one more layer of validation. It makes sense to allow our own root CA issue the client certificate but I also want that extra DV certificate validation. So you are saying I can pin that to the client certificate that I will provide? Our goal was to add an extra layer of validation to ensure the company is legitimate and the OV certificate would provide that
    – Decrypter
    Jul 10, 2022 at 20:14
  • @Decrypter: if you want or revoke trust on top of another CA then cross-signing isn't the right way anyway, since it relies on trusting at least one of the involved parties while you want to check trust for all the involved parties. In this case certificate pinning on top of normal certificate validation can be done. But it can not be done that the same certificate is signed by multiple parties and each must be checked.
    – Steffen Ullrich
    Jul 11, 2022 at 5:31
0

Assuming that the DV certificate was issued by a commercial CA (such as Let's Encrypt) and your system has a reasonably up-to-date trust-anchor store (a collection of trusted Root CA certificates), then you are already trusting their DV cert. You trust the Root CA, therefore you implicitly trust all certificates issued by the Root CA and any subordinate CAs of that Root. That's the first half of mutual authentication done - the server authentication. This is no different to browsing any website, such as ServerFault, where your client (browser) trusts the certificate sent by the server, which was issued to it by a commercial CA (Let's Encrypt in this case).

For the other half - the client authentication - you need to get them to trust a certificate presented by you during the initialisation of the mutual TLS session. That is, you need to have a client authentication certificate issued to your system, which it presents to the server to authenticate itself.

Between the server authentication (1st paragraph above) and the client authentication (2nd paragraph), you now have mutual authentication. Remember that with mutual authentication, your end verifies their server certificate; while their end verifies your client certificate - hence mutual.

The remaining problem is how to issue yourself a client certificate which your customer will trust. You have two options:

  1. Either you need a cert issued to yourself by a CA they already trust (the Root CA certificate is already in their trust-anchor store); or,
  2. you need to get them to trust your private CA (add your Root CA certificate to their trust-anchor store) and issue yourself a cert from that CA - but getting your Root CA cert added may be a challenge if they have strict governance of their PKI within their organisation.

You cannot cross-sign for mutual TLS - cross-signing is for different purposes.

Improve this answer
3
  • I think providing them a client certificate that is generated from our CA will be fine. However unsure how the DV cert can be validated. Can you clarify when you say You are already trusting their DV cert - that's the first half of mutual authentication they can send that with the client cert I provide so I can validate both?
    – Decrypter
    Jul 10, 2022 at 20:18
  • You do not need to provide them a client certificate - you need one of those for your system. I've updated my answer to try and clarify.
    – garethTheRed
    Jul 10, 2022 at 20:54
  • Got what you are saying. Thanks a lot for clarifying. I added some more information to what I am doing Based on that, I am thinking if we have the mTLS in reverse since the TLS connection requirement can happen later on in the session. The customer will be specifying a callback url which we send data to it when ready. So if we send our certificate to them so they do server authentication. We are the client now and they provide their certificate which we trust. We might want to do extra checks on their cert (domain name, company name, etc) Sorry if a little spotty. I'm learning
    – Decrypter
    Jul 10, 2022 at 22:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .