tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Deploying .ca-bundle file & .crt file as SSL certificates
Date Wed, 26 Nov 2014 18:21:02 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

To whom it may concern,

On 11/26/14 12:00 PM, Kernel freak wrote:
> On Wed, Nov 26, 2014 at 5:33 PM, Christopher Schultz < 
> chris@christopherschultz.net> wrote:
> 
> To whom it may concern,
> 
> On 11/26/14 9:03 AM, Kernel freak wrote:
>>>> After arguing with the admins for all this time, I finally
>>>> have the few files ready. I have the following files :
>>>> 
>>>> keystore.p12
> 
> That should contain your key. Can you confirm that with a 'keytool
> -list'?
> 
>>>> server.crt
> 
> Is this the certificate that was signed by the CA?
> 
>> Yes, this is certificated signed by CA, but its a
>> servercertificate, the domain certificate is below.

I have no idea what a "domain certificate" is. A cert is a cert, and
it's signed by another cert all the way up to a root cert, known as a
CA who has widespread trust.

>>>> ssl-cert-snakeoil.key
> 
> Uh, oh. That looks like one of OpenSSL's built-in CAs that are
> used for documentation and instructional purposes. I hope this
> isn't being used for anything at all.
> 
>>>> domainname.com.ca-bundle
> 
> This should be the bundle of certificates for your domain, which
> may include intermediate certificates. Are you using your own
> internal CA or something?
> 
>>>> domainname.com.crt
> 
> Which certificate is this?
> 
>> This is the SSL certificate which has to be deployed.
> 
> 
>>>> domainname.com.csr
> 
> Is this the CSR that you generated yourself?
> 
>> No, this is also provided by hosting guys

So, did your "hosting guys" generate everything for you, then? It's
customary to create your own key and CSR and then merely have the CA
sign the CSR which results in your certificate. You import your
certificate and, if necessary, any intermediate certificates your
clients will require to form a trust chain from your server's cert up
to the root that the client trusts.

>>>> domainname.com.key
> 
> 
> 
> Weird. Okay, I would expect domainname.com.key to have the key
> that was used to generate domainname.com.csr, and that
> domainname.com.crt is a signed version of that CSR. That should be
> all you need... I'm not sure what all the other stuff is.
> 
>>>> vsftpd.pem.
> 
> What is this?
> 
>>>> I did the following as Christoph said:
>>>> 
>>>> root@domainname:/etc/ssl/private# openssl pkcs12 -export -in 
>>>> server.crt -inkey ssl-cert-snakeoil.key -certfile 
>>>> domainname.com.crt -out keystore.p12 -chain  (pressed enter
>>>> here) unable to load certificates  // This is the error.
> 
> I think you might want to do this:
> 
> $ openssl pkcs12 -export -in domainname.com.crt \ -inkey
> domainname.com.key \ -certfile domainname.com.ca-bundle \ -out
> keystore.p21 -chain
> 
> $ keytool -importkeystore -srckeystore keystore.p12 \ -srcstoretype
> pkcs12 \ -destkeystore keystore.jks
> 
> You are supposed to be able to use PKCS12 keystores directly with 
> Tomcat, but IIRC it's a pain and a bit more finicky than with just
> a "normal" JKS-format keystore.
> 
>>>> If i just plain import the .crt file like this :
>>>> 
>>>> keytool -import -alias tomcat -file domainname.com.crt
>>>> -keystore /root/.keystore
> 
> A couple of things:
> 
> 1. Don't run as root. Not for anything. Not even to run keytool. 2.
> Don't store your keystore under /root/.keystore, or you'll
> (likely) have to run Tomcat as root. You can put your keystore
> anywhere you want and point Tomcat to it explicitly. 3. If you
> import a certificate into a keystore and there is nothing else in
> it (the keystore), then you can't perform a handshake because the
> key is required for secure communication.
> 
>>>> Then firefox gives me this error :
>>>> 
>>>> An error occurred during a connection to
>>>> domainname.com:8443. Cannot communicate securely with peer:
>>>> no common encryption algorithm(s). (Error code:
>>>> ssl_error_no_cypher_overlap)
>>>> 
>>>> The page you are trying to view cannot be shown because the 
>>>> authenticity of the received data could not be verified.
>>>> Please contact the website owners to inform them of this
>>>> problem.
> 
> The no_cipher_overlap error is likely to be incorrect... the real 
> problem is that the server can't decrypt the client's handshake 
> because the key is unavailable.
> 
> I think you might need to get some help with this from someone else
> at your organization... someone who is a bit more versed in PKI
> and configuring TLS for web servers.
> 
> 
>> I have told you what key is for what, can you give me the updated
>> commands please, unfortunately there is no one here who knows
>> this.

I can't understand something on your behalf: you have to understand it
yourself. Once you understand what is going on, these commands will
make sense and you should be able to execute them without guessing.

If you can't figure it out, hire someone who already knows.

The only weird part about Java keystores is the use of an "alias"
which allows you to pack a keystore full of all kinds of goodies and
then refer to specific items by their names (I don't know why CN isn't
a good enough identifier, but I guess keystore wonks thought it would
be a good idea). It's not a bad idea to give every item in your
keystore (key, certificate, etc.) an alias so you can be explicit
about which one you are talking about. I also recommend NOT packing
too much crap into a keystore: keep things simple and only put a
single key, your server's certificate and the chain required for the
CA into your keystore.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUdhoOAAoJEBzwKT+lPKRYnRQP/1rtTlzApmOFLnhMkcRcp2gv
KF8tsyl/KA78KKuZ7bjZUmhyPC+z74+x2Vu7PPCKYzwb/b3jv5tjpiOI05Yw1+Pm
1kI9Wiuzws/B7k6CThZ9vb5+eQIRz8g6qnDkmcJw8Ie5iyNQS0eXAuJglyCRiV+x
Uq2liMCp5c4ehDJg19HIhKox268Sl8UdtTS7VW3R5W/CniN0XH0ODNJOXRAFw4b6
zi9uo9jGR9x/i4cgT6cRKa/1K7dkIEcQ0c+XwmTzln52gbKLuhTpqGoTeIleVo+B
kdwim+YRhC8gtkltEDZ8LMnIw9hDuoMpbSSm7i6f2xBJ8ytBcmMpVs6Vw7qmfNBv
3aWV0bkiyz0qLLHaz8fh3RXbaT6bHpi18re89Pu+PDEnr2teoojmOjo+Kc5Yxh9h
Q2Pp5JlnK8chZncNU0tha+R9JZv+EE/GQaZwL+8WEtyvyYDZY86ZXysaPCBpOjMi
pIR0vjogh7i4nzK7fQrZOAW8vzx4wBE6Wb/Qh7/z9lcKCKmDQkgiolu3LWdAWxcm
IQ+KSlDqBCPvIt6+fn9JRWGVSTEzD1tzdhkebTuRNDZF4a2NrZxu+AGnUbxpAxM1
WnFd7y0IvfGvEfN04xjA4k4LL/IdQOqL1QRckFfgeTjigdvP2mc7XaylEPfDcUqt
9kjUClYiPQACEz1LiLo1
=1y/y
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message