Isn‘t that what client certs are for? Https to identify Server A, Client cert to authenticate Server B?
Message integrity should then be unnecessary?! Or am I missing a piece? Peter > Am 09.09.2019 um 21:10 schrieb M. Manna <manme...@gmail.com>: > > Why not use JWT cookies/tokens? You sign your claims and only you can > validate the claims and ensure that it’s coming from the right place/user. > > Thanks, > >> On Mon, 9 Sep 2019 at 19:26, Michael Duffy <mduffy...@gmail.com> wrote: >> >> I need to communicate securely between two Tomcat servers running in two >> different environments. I have control of both servers. >> >> I would like to do this through a simple REST call from Server-B to >> Server-A. >> >> On the server I am communicating to, Server-A, I can easily set up HTTPS >> with a self-signed certificate. If I import this certificate into the Java >> Keystore on Server-B, I can make a trusted HTTPS Rest call from my Java >> code on Server-B. >> >> Good instructions for doing this can be found here: >> >> https://blog.10pines.com/2017/09/25/how-to-communicate-via-https-between-two-tomcat-servers-using-a-self-signed-certificate/ >> >> >> I would also like to add a confirmation that the Rest call to Server-A is >> certainly coming from Server-B and the message has integrity. >> >> My plan is to generate a self-signed certificate on Server-B and import >> this certificate into the Java Keystore on Server-A. Then for any REST >> call from Server-B I will first generate an SHA-512 hash of the message and >> sign the hash with the private key associated with the Server-B >> certificate. When Server-A receives the message, the SHA-512 hash will be >> recalculated and checked for accuracy of the hash (no message tampering). >> I will then check the signature of the Hash against the public key of the >> certificate from Server-B. >> >> For a little bit of extra paranoia I may encrypt the REST message with the >> public key of the certificate from Server-A; for short messages this should >> be fine (no need for Symmetric encryption). >> >> Does this seem like a good plan? >> >> Thx in advance for any suggestions. >> >> Mike >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
