For an embedded industrial application, I want to use TLS to encrypt HTTP communication. I'd like to offer users easy to use options if there is no PKI readily available.

What are my choices here, to ensure best compatibility?

I thought about using TLS-PSK (users then would simply need to configure the PSK on both client and servir sides), but compatibility is a disaster. Most HTTP(S) clients (e.g. curl) or client libraries simply do not support TLS-PSK at all.

I also considered certificate pinning with server-side automatically generated self-signed certificates, so that no CA is required. Users would then only have to copy and import the certificate on the client side. The typical check of common name against the hostname would typically have to be disabled as well. Again, most HTTP client libraries don't really support this scenario.

Are there any other options available that I am missing?

migrated from crypto.stackexchange.com Apr 15 at 12:14

This question came from our site for software developers, mathematicians and others interested in cryptography.

  • 3
    There is a standard (RFC 7250) for using raw public keys with TLS. – SEJPM Apr 14 at 10:52
  • Thanks, that sounds pretty neat, but software support for that is even worse. OpenSSL doesn't support it. – dietr Apr 14 at 11:17
  • 1
    I think this is less cryptography and more applied security, i.e. more on-topic at Information Security. Apart from that the restrictions of your use case are not fully clear. But if you need to use common HTTP libraries then there is likely no way around certificates, i.e. either with your own small CA or with self-signed certificates. Disabling validation of everything but the key will be a problem though since many can only disable validation at all (this is what you don't want) and not for specific features of the certificate. More information about your software stack would probably help. – Steffen Ullrich Apr 14 at 12:50
  • 1
    Could you please elaborate "No PKI support available" further? – MechMK1 Apr 15 at 12:36
  • 4
    Again, please provide details about the software stack you need to use and other restrictions. All what you did so far is to reject ideas from yourself and others since they don't work in your specific environment without actually providing the restrictions. Based on this one could only speculate what works and what not and the risk that you will reject the next idea because it will not work either. In other words - in the current form the question is not specific enough , i.e. too broad. – Steffen Ullrich Apr 15 at 13:33

Your Answer

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

Browse other questions tagged or ask your own question.