This can be a pain, but it's easy once you've done it once or twice.
On the guide you're looking at, it SOUNDS like you're already past the "generate a new key" and "generate CSR" steps. You're probably starting at or near the "Import CSR to gateway certificate" step.
I actually use Keystore Explorer, an open source certificate management tool that basically just puts a UI on these openssl / keytool type commands.
Protip: Don't forget to "append certificates" to your chain. "Out of the box" you're dealing just with the (signed) certificate and it's private key. You want to import the intermediate and root certificates too so that the gateway will present both of them in addition to its head certificate when someone connects to you (or you connect to someone else).
Most clients/servers these days don't care if they get the intermediate/root certificate, but some old ones might still complain, and from what I've seen it's a tested-for requirement by EHEX.
The private key is part of the keypair you generated as a prelude to generating a CSR. It's the CSR that you sent to the folks at EHEX. They used the CSR to generate you a new public certificate in their "CSR Reply" AKA "CA Reply".
The keypair is likely something along the lines of "gateway.jks"; you would have generated this.
From a Keystore Explorer context, you want to open the .jks that has your private key and use the "Import CA Reply" functionality to replace the original (self signed) public key with the CA-signed certificate they provided you.
0) Don't panic! Certs are a pain.
1) Download and use KeystoreExplorer if you aren't already
2) Rename the existing gateway.jks in your ..../main/ directory to something else (e.g. gateway.jks.backup)
3) Create a new .jks ("Create a new KeyStore" option in KeyStore explorer for example; chose JKS option). Name it "gateway.jks". This should be in the same ..../main/ directory.
4) Import your original private key and public key from when you generated the certificate and CSR, give it the alias of "gateway". It sounds like these are the "servercert.bin" and "servercer-private-keys.bin" files. I'm not sure what format those are at the moment, but a little massaging with KeystoreExplorer should sort that out for you.
5) Use the "import CA reply" function to get that updated certificate
6) Append the certificate chain as discussed in my comments above
7) Make sure cacerts.jks has OS level ownership that the user that runs CONNECT/Wildfly can use (easy cheat: the same ownership that the gateway.jks.backup and/or other files in the same directory have/had)
8) Restart wildfly
9) Check the logs. Post any stacktraces you see here.
From what I can intuit, I think your servercert.bin is the equivalent of the "/tmp/cert/gateway.pem" certificate.
The example seems to contain an error (looks like copy/pasting to make a guide ex post facto) in that it points to the "same" file twice "/tmp/cert/cert3.pem".
In any event, you'd want to get the Intermediate Entrust certificate (available on the same webpage where you actually submitted the CSR and entered your passcodes) and the Root certificate that signed it (that'll take a little more digging) and import them as well.
The way Keytool works, I actually don't think the order really matters. It also looks to me that you're importing just the certs; I'd expect to see somewhere in there that you are importing a whole *keypair* that contains the public cert and its corresponding private key all at once.
This is usually an "importkeystore" command along the lines of this:
So here is what I have accomplished, just looking for next steps:
- Using Keytool Explorer I created a 'new', gateway.jks keystore file
- Added the 'public' and 'private keys' from the generated certificate from Entrust
- Imported into the 'gateway.jks' file via Import CA reply from my servercert.cer file
I have downloaded the 'intermediate' cert from Entrust, now I just need to figure out how to obtain
the 'root' certificate from it before proceding through the rest of the import (chaining) process.
In general terms, you use the information on a "more junior" certificate to be able to find it's "parent" (signer) in the chain. So, you can use information on the head certificate to find the intermediate, and similarly you can use information on the intermediate to find the root.
Essentially there's a link of sorts on the intermediate that lets you download a certain kind of truststore which you can open and it will contain, in this case, about 10 or so versions of the Root certificate- some of these are expired or revoked or otherwise have been re-issued. You need to match the certificate by... If I recall right... serial number, based on the information on the Intermediate's "Authority Identifier" if I recall right.
(Apologies, I don't have a setup handy to confirm in more detail)
I would be able walk through this in Keystore Explorer, but this is really the kind of thing I'd do for a client over a screenshare or something- I'd need to have it right in front of me to work through it.
I did find this link; the topvoted answer describes steps to do this using openssl (I haven't verified them myself but the description is about right)
Give that a try, and if you're still stuck, I'd like to point you to the link to the "Free 15" in my tagline; this is a way that we at Zen set up for technical folks to reach our technical staff for some tech-to-tech talk, intended for talking through technical issues at a mid-level and, if appropriate, talking through some options to bring us in to help out directly.