1

I have a CA generate a cert and private key for my server. My server, however, does not have a domain name and its IP is dynamic and never static therefore validation of the host name must be ignored on the clientside. I know this is not true and traditional HTTPS, let's just say for argument this has to occur.

I have a client that tries to send my server a payload over HTTPS post. During the handshake, I check the CA of the server and proceed to send the payload if it validates. I don't care if the server rejects the request or not, the client just fires and forgets once handshaked. The client rejects ALL CAs except the one trusted CA.

Is it possible for someone to see the payload the client sends in this scenario besides my server? Say for example I send the request to an IP over HTTPS thinking it is the server I want, but it's actually someone malicious. Is there anyway they can spoof or pretend to be the actual server and accept the request in order to look at the payload of the POST? In order to get the payload, they have to be able to say "I am the server and have a cert signed by the CA you trust" is my understanding. But how can you do that unless you have both the server's cert and the CA? Where does the private key of the server's cert factor in?

If yes, what if I use a CA only the server and client know about like a self signing authority? Does that change anything, if not why?

1

There are several scenarios that make it possible to intercept that connection:

  • Your validation code is not actually validating correctly in which case another CA might sign certificates that are deemed valid by your code.
  • Your CA's private key gets leaked, lost or otherwise compromised (for example because it gets factorized) in which case anyone in possession of the key can sign themselves a certificate that is deemed valid by your code.
  • same thing (compromised key) for your actual certificate.
  • Your CA might not be under your control completely (i.e. not your own CA) in which case any certificate signed by that CA (for example, any TLS certificate for any domain, if your CA is a provider of domain TLS certificates (like, for example, let's encrypt)) is deemed valid by your code.

To mitigate the last possibility, you could use a self signed certificate authority that you explicitly trust in your client application, but this comes with the usual caveats of that, i.e. understanding what you're doing and keeping the CA itself safe.

But how can you do that unless you have both the server's cert and the CA? Where does the private key of the server's cert factor in?

This question does suggest that you are not actually understanding how a PKI or TLS works and thus that hosting your own CA might come with an increased security risk.

The general idea is that the CA is not on the same machine that the certificate is deployed on - please do read up on PKI, TLS, certificate pinning and trust chains before you proceed employing your own CA.

  • Thanks for the detailed information. It's mainly your 4rth bullet point that concerns me the most. I have a cert generated from my CA. Looking at the cert's issuer, it's a common one. Let's say the issuer is a Verisign Intermediate for examples sake. If I am a malicious user and I have a cert signed by the same Verisign Intermediate, you're saying I could receive the request and inspect the payload intended for a different server just because the CA is common? – user99999991 Jan 22 at 8:08
  • 1
    Yes, that is how the trust chain works if you do not employ certificate pinning. – Tobi Nary Jan 22 at 8:09
  • Thank you again. I believe this has answered my qquestion and covered my concerns. I've marked it as the accepted answer. For the record it wasn't my intention to imply the CA would be on the same server the cert is made for use on. But it's worthy to note anyway. Protecting both the cert's private key and the CA itself separately is imperative. – user99999991 Jan 22 at 8:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.