How to use another SSL certificate for DHE-RSA while I already have one with domain?

Question

I'm working in IOT team to build a web based IOT system.

I'm using Dataplicity's Wormhole to host my nodeJS app on raspberry pi. I want to use DHE-RSA symmetric key encryption channel for sending/receiving data from client to server and vice-versa.

In case of DHE-RSA server generate DH parameter and then sign them with SSL private key and send it to the client. But, here Dataplicity host my website on a subdomain which have SSL, So, i don't know the key pair. Can I use another SSL to for DHE-RSA.

If, yes and how to send the certificate to client. Because, SSL is attach with domain but here the domain is third party's. So, in this situation how to solve this?

Thanks in advance...

Answer 1

The root of the problem is that your pi web server is running behind a NAT firewall. Therefore, it is impossible (without port forwarding) for outside users to connect to your pi web server through the firewall.

Dataplicity's solution solves this problem using a proxy server of sorts. If you look at the diagram at https://docs.dataplicity.com/docs/how-it-works, your pi first connects to Dataplicity's server (the NAT firewall allows this, because it's an outgoing connection). Then outside users connect to Dataplicity's server, which then forwards their requests to your pi web server, and forwards the responses from the pi web server back to the users. But, because outside users are connecting to Dataplicity's server (at *.dataplicity.io), the certificate that they see is for *.dataplicity.io. This also means that *.dataplicity.io is able to access (and modify) the plaintext of the requests and responses as the are relayed to and from your pi web server. They are essentially a man-in-the-middle.

A solution to this problem is to setup a public facing server (it can be a VPS). Then, from the pi, create an ssh tunnel between the pi and the public server, such that incoming https connections to port 443 on the public server are forwarded back to the pi. Then, point the A record for your FQDN to the public server, and go ahead and create your RSA keys on the pi, create a CSR for the FQDN (containing the RSA public key), get it signed by a CA, and configure the web server on the pi to use the cert and the private RSA key for TLS. Then when a user points their browser to FQDN, they'll in fact be connecting to the pi (through the public server). The certificate that the user sees will be the one that you created for your FQDN, and the TLS connection will be established using this certificate and the underlying RSA keys that you've created on the pi. Then, all the public servers sees is the encrypted traffic passing through it. If you specifically want the pi server to only allow TLS_ECDHE_RSA cipher suites, you can specify this in the web server configuration on the pi.