You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Darryl Philip Baker <da...@northwestern.edu> on 2020/08/28 21:19:01 UTC
Red Hat / CentOS specific question about certificates
I am having an issue that I don’t understand. On RHEL6/CentOS and earlier my predecessors would put self-signed certificates they wanted to trust in /etc/pki/ca-trust/extracted/java/cacerts and it was good for the life of the machine. On RHEL7 and I assume CentOS7 that file is part of a package that is getting updated as part of the regular patches. That wipes out our self-signed certificates. The way I understand the directions from Red Hat we should put the certificate in pem format in the directory /etc/pki/ca-trust/source/anchors and run update-ca-trust extract and that will update the all the appropriate files. Including the cacerts file. That does not seem to happen. What is the proper way of handling self-signed certificates you want tomcat to trust?
Off topic but you are folks who might know:
On a related note I have the same issue with Java applications not running in Tomcat that use the same file /etc/pki….java/cacerts. Am I understanding the PKI update process correctly? Am I putting the self-signed certificate pem format file in the correct place?
Darryl Baker, GSEC (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
1800 Sherman Ave.
Suite 6-600 – Box #39
Evanston, IL 60201-3715
darryl.baker@northwestern.edu<ma...@northwestern.edu>
(847) 467-6674
Re: Red Hat / CentOS specific question about certificates
Posted by Daniel Savard <da...@gmail.com>.
Le sam. 29 août 2020 à 09:05, Darryl Philip Baker <
darryl.baker@northwestern.edu> a écrit :
> I will argue that you can use self-signed certificates in production if
> and only if you own and fully control both servers engaged in transaction
> as well as all of the connection fabric between the servers. If these
> conditions are true and someone can execute a man-in-middle attack, I will
> assert that your environment are already so compromised the attack is
> almost meaningless. On the other hand, using a self-signed certificate with
> an expiry of greater than 398 days in a situation as this means that you
> can free up people's time to do other work other than maintaining a hidden
> certificate. And setting up automation to renew said certificate such as
> this, adds an increased level of complexity as well as an additional point
> of failure to the equation.
>
>
> Darryl Baker, GSEC (he/him/his)
> Sr. System Administrator
> (...)
It all depends on the size of your environment and how you use Tomcat.
Having over 30 servers and thousands of users, self-signed certificates
cannot just be a solution. You have to have each self-signed certificate on
each client accessing the environment to override the security warning
message (in fact, I am not sure it will even go away). Telling your users
to ignore the warning is just not the thing to do since next time they see
the message in another context they may just accept the insecure
connection. And with over 30 servers, automation makes sense for me. Even
for people without the expertise, the Let's Encrypt Certificate Authority
provides short life certificates that are replaced automatically and it
works fine. Getting a properly signed certificate these days is not the
hassle it was, in fact it may just be easier than issuing a self-signed
certificate.
Anyway, it is up to you to decide what you want and if your question is
finally just about what RedHat is doing with that file, you may be better
served on a RedHat discussion list since it ends up being a RedHat only
question having nothing to do with Tomcat itself. From the Tomcat point of
view, you can only copy the file somewhere else where the RedHat scripts,
update procedures will not touch it and let Tomcat know where it is.
Regards,
-----------------
Daniel Savard
Re: Red Hat / CentOS specific question about certificates
Posted by Darryl Philip Baker <da...@northwestern.edu>.
I will argue that you can use self-signed certificates in production if and only if you own and fully control both servers engaged in transaction as well as all of the connection fabric between the servers. If these conditions are true and someone can execute a man-in-middle attack, I will assert that your environment are already so compromised the attack is almost meaningless. On the other hand, using a self-signed certificate with an expiry of greater than 398 days in a situation as this means that you can free up people's time to do other work other than maintaining a hidden certificate. And setting up automation to renew said certificate such as this, adds an increased level of complexity as well as an additional point of failure to the equation.
Darryl Baker, GSEC (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
1800 Sherman Ave.
Suite 6-600 – Box #39
Evanston, IL 60201-3715
darryl.baker@northwestern.edu
(847) 467-6674
On 8/28/20, 7:47 PM, "Daniel Savard" <da...@gmail.com> wrote:
Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
darryl.baker@northwestern.edu> a écrit :
> I am having an issue that I don’t understand. On RHEL6/CentOS and earlier
> my predecessors would put self-signed certificates they wanted to trust in
> /etc/pki/ca-trust/extracted/java/cacerts and it was good for the life of
> the machine. On RHEL7 and I assume CentOS7 that file is part of a package
> that is getting updated as part of the regular patches. That wipes out our
> self-signed certificates. The way I understand the directions from Red Hat
> we should put the certificate in pem format in the directory
> /etc/pki/ca-trust/source/anchors and run update-ca-trust extract and that
> will update the all the appropriate files. Including the cacerts file. That
> does not seem to happen. What is the proper way of handling self-signed
> certificates you want tomcat to trust?
>
> Off topic but you are folks who might know:
> On a related note I have the same issue with Java applications not running
> in Tomcat that use the same file /etc/pki….java/cacerts. Am I understanding
> the PKI update process correctly? Am I putting the self-signed certificate
> pem format file in the correct place?
>
> Darryl Baker, GSEC (he/him/his)
> Sr. System Administrator
> (...)
>
>
You can put your certificates and truststore wherever you want as long as
you tell Tomcat where they are in the conf/server.xml configuration file
when you configure the connector using them. Self-signed certificates
should never be used on a production server, they are not secure. It is up
to you to handle the certificates when they expire unless you have some
other automated way to renew them. Normally, the cacerts file distributed
with Java is a JKS formatted trust store and the certificates it contains
will eventually expire. That's why when Java is updated you may get an
updated cacerts file as well. If you put your own certificates in that file
and it gets updated when Java is updated, obviously you will lost your
certificates. Just make a copy and put your certificates in the copy. In
fact, you may not need the original file at all if only self-signed
certificates are involved. All the certifications authorities in the file
are then useless to you.
Regards,
-----------------
Daniel Savard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Red Hat / CentOS specific question about certificates
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Daniel,
On 8/31/20 16:28, Christopher Schultz wrote:
> Daniel,
>
> On 8/31/20 11:36, Daniel Savard wrote:
>> Le lun. 31 août 2020 à 11:13, Christopher Schultz <
>> chris@christopherschultz.net> a écrit :
>
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>>
>>>
>>> Daniel,
>>>
>>> On 8/28/20 20:46, Daniel Savard wrote:
>>>> Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
>>>> darryl.baker@northwestern.edu> a écrit :
>>>>
>>>>> I am having an issue that I don’t understand. On
>>>>> RHEL6/CentOS and earlier my predecessors would put
>>>>> self-signed certificates they wanted to trust in
>>>>> /etc/pki/ca-trust/extracted/java/cacerts and it was good
>>>>> for the life of the machine. On RHEL7 and I assume CentOS7
>>>>> that file is part of a package that is getting updated as
>>>>> part of the regular patches. That wipes out our
>>>>> self-signed certificates. The way I understand the
>>>>> directions from Red Hat we should put the certificate in
>>>>> pem format in the directory
>>>>> /etc/pki/ca-trust/source/anchors and run update-ca-trust
>>>>> extract and that will update the all the appropriate files.
>>>>> Including the cacerts file. That does not seem to happen.
>>>>> What is the proper way of handling self-signed certificates
>>>>> you want tomcat to trust?
>>>>>
>>>>> Off topic but you are folks who might know: On a related
>>>>> note I have the same issue with Java applications not
>>>>> running in Tomcat that use the same file
>>>>> /etc/pki….java/cacerts. Am I understanding the PKI update
>>>>> process correctly? Am I putting the self-signed certificate
>>>>> pem format file in the correct place?
>>>>>
>>>>> Darryl Baker, GSEC (he/him/his) Sr. System Administrator
>>>>> (...)
>>>>>
>>>>>
>>>> You can put your certificates and truststore wherever you
>>>> want as long as you tell Tomcat where they are in the
>>>> conf/server.xml configuration file when you configure the
>>>> connector using them.
>>>>
>>>> Self-signed certificates should never be used on a
>>>> production server, they are not secure.
>>> What makes you say that?
>>>
>>> - -chris (...)
>
>
>
>> https://www.venafi.com/blog/self-signed-certificates-cyber-criminals-
a
>
>>
re-turning-strength-into-a-vulnerability
>
> This
>
> article is talking about securing miscreants' communications. It
> really has nothing to do with self-signed certificates. It has to
> do with users blindly "trusting" anything which claims to be
> trustworthy just because it's encrypted.
I've re-read this article and also read their linked article on
Heartbleed, and I have come to the conclusion that the writers do not
have any clue what they are talking about.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NYTEACgkQHPApP6U8
pFgDwQ/+J1fhYRIMEjcDOhYmdtX6d3cid7pQ9pjBq3LePbeT+KrFWn7GbJcSU3Bg
SpBzZJUg2KB1EzMaZFmXd/OBpdrq+1a08fdjvwnDB1nSmznuIpgRbagm6MWigFlm
ghW5+96nQ/6L3a8LTZrjCkO7jxwuIMISYSOLvm9d9m7IHpgKWRl5UjBC/EuWpof6
blApEICEh4sWE9ZEBSYsphba3wP9nAFEKIb0/7ORRvQqkYZtSe/cQsTNXVOTQ9GF
nBcT40jMnG3pvEKzz7Gjk+OXhe3tAATBMdCvwzGtmct4QKI7T1B1FWHKZod1zgne
FqkX2ryRoq8F8MgDMkamzAQsW+n9WYVfQYDCaLMmoE2x3D3lulOUngL6g4qaA95u
TGdeggVgIaOmeJclImbuvE/X2fA89D90sc0XuGbUcXa4uvm8l13RDZVRyuntoXMQ
puMXypG0wRqlqfvA3ab4K+gI0AHjZ5tCJeqKMpUV+yOKDlB5ii0YBp6nB21x7C+4
afi4LXgIJsmXMpUp0ggjBmshrJ0KM5rnIdlpCdRKpuKic3Wy+C7sV0FxwOtx5bhj
JI/Er4uVeBpXh0gWYpTko+3SqpEPOkdFlCNbPBUZ0UtdeK8BWbQPTpi4evumMj8Z
WgLZ+FRS7mD3NAIRERrDKpAsKQK1vmU9t6OfZXV+zE+sZ3n6ap0=
=4OMv
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Red Hat / CentOS specific question about certificates
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Daniel,
On 8/31/20 11:36, Daniel Savard wrote:
> Le lun. 31 août 2020 à 11:13, Christopher Schultz <
> chris@christopherschultz.net> a écrit :
>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>>
>> Daniel,
>>
>> On 8/28/20 20:46, Daniel Savard wrote:
>>> Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
>>> darryl.baker@northwestern.edu> a écrit :
>>>
>>>> I am having an issue that I don’t understand. On
>>>> RHEL6/CentOS and earlier my predecessors would put
>>>> self-signed certificates they wanted to trust in
>>>> /etc/pki/ca-trust/extracted/java/cacerts and it was good for
>>>> the life of the machine. On RHEL7 and I assume CentOS7 that
>>>> file is part of a package that is getting updated as part of
>>>> the regular patches. That wipes out our self-signed
>>>> certificates. The way I understand the directions from Red
>>>> Hat we should put the certificate in pem format in the
>>>> directory /etc/pki/ca-trust/source/anchors and run
>>>> update-ca-trust extract and that will update the all the
>>>> appropriate files. Including the cacerts file. That does not
>>>> seem to happen. What is the proper way of handling
>>>> self-signed certificates you want tomcat to trust?
>>>>
>>>> Off topic but you are folks who might know: On a related note
>>>> I have the same issue with Java applications not running in
>>>> Tomcat that use the same file /etc/pki….java/cacerts. Am I
>>>> understanding the PKI update process correctly? Am I putting
>>>> the self-signed certificate pem format file in the correct
>>>> place?
>>>>
>>>> Darryl Baker, GSEC (he/him/his) Sr. System Administrator
>>>> (...)
>>>>
>>>>
>>> You can put your certificates and truststore wherever you want
>>> as long as you tell Tomcat where they are in the
>>> conf/server.xml configuration file when you configure the
>>> connector using them.
>>>
>>> Self-signed certificates should never be used on a production
>>> server, they are not secure.
>> What makes you say that?
>>
>> - -chris (...)
>
>
>
> https://www.venafi.com/blog/self-signed-certificates-cyber-criminals-a
re-turning-strength-into-a-vulnerability
This
>
article is talking about securing miscreants' communications. It
really has nothing to do with self-signed certificates. It has to do
with users blindly "trusting" anything which claims to be trustworthy
just because it's encrypted.
Self-signed certificates by definition are not signed by a CA, so they
are not globally-trusted (or even semi-globally-trusted). "Trusting
All" certificates is a terrible mistake and the only way that
self-signed certificates can be a problem, whether used on an
"internal" network or exposed to the outside network.
> Never may be exaggerated in my post. But in general, you should
> avoid them.
Meh.
> But it all depends on your organization as well, mine is signing
> internal certificates and managing to include itself in the
> browsers of all the thousands employees.
This is a good technique IMO.
> In a small business, it may not be possible and the number of
> self-signed certificates may be low. In our organization, in the
> past we have seen people setting up their own self-signed
> certificates with too short keys to be secured by today's
> standards.
Well, that's obviously a mistake.
Especially if you aren't talking about browser-trust, I think
self-signed (or local-CA-signed) certificates are a good thing.
Services ought to be individually-trusting service certificates and
not even accepting all globally-recognized CAs because a compromised
CA or middle-box can intercept communications without a problem.
Self-signed certificates offer isolation from CAs and can therefore be
*more* secure for service-level certificates precisely because they
require special deployment.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NXWQACgkQHPApP6U8
pFicIxAAj04SbtcGa7UuCb65EvME1XAqRRwmsHVBGhLxBK/Nr3g+hDZ9xFd9Yo4i
5iuQ0yat4lD2y8BH1YF+EHrygfIp86EoDUKKukjuoAVQ4cgHFM6T2aoM8sWJR1CJ
xoxbA+dWnYL12BZR6jRj2k5vcOvs/UYkz4A6dp9X2N1LaQHMw5/orrqLPwN/BxiZ
qTzeEKqMAhLsfGVZVs9VGZPMLZYL6TvMkca22IltK1Z3dDkalijwyL83Q7vVGEvm
38qamO3FkgnfjZPgufkVoxfEKkG3lmMY7kpzxvGeoaPaH3he3tljXXVGbKxfSAuX
NFYj1CciL2fJCGm0roIB/9kPvG3Eoiq96ubUwbpl2fIciMA+XFJ6nUDj0ogdHzl1
yYbAowAXN4YR7azmmhwSUzgUsaw5itAQxiQpb0A7G3yxmTt52xv62aV5PhDw0lsN
HULi7GFm6JoeuzaGW6KBcOfBu+hZpek1Jqujn/Y435jIU5otE9R+yYDtdonLD0W3
ssWGdZRP6/Rgu41BEMPpdCgb+lDWBH/EkuTFHDerX2u9kpjALuJTTPRyt2REpOqY
Oflifwm2f9R77J3LNK8CNqC9d1BtUJqwSJ5/u+dRpkExYzTf37mHkt2kmdDlZJYi
mpjJUuoyEZnxhltyrp8Wn5bWNnA6P4kzVcPGqbG3MM/1KIHs++k=
=kmkH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Red Hat / CentOS specific question about certificates
Posted by Daniel Savard <da...@gmail.com>.
Le lun. 31 août 2020 à 11:13, Christopher Schultz <
chris@christopherschultz.net> a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
> Daniel,
>
> On 8/28/20 20:46, Daniel Savard wrote:
> > Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
> > darryl.baker@northwestern.edu> a écrit :
> >
> >> I am having an issue that I don’t understand. On RHEL6/CentOS
> >> and earlier my predecessors would put self-signed certificates
> >> they wanted to trust in /etc/pki/ca-trust/extracted/java/cacerts
> >> and it was good for the life of the machine. On RHEL7 and I
> >> assume CentOS7 that file is part of a package that is getting
> >> updated as part of the regular patches. That wipes out our
> >> self-signed certificates. The way I understand the directions
> >> from Red Hat we should put the certificate in pem format in the
> >> directory /etc/pki/ca-trust/source/anchors and run
> >> update-ca-trust extract and that will update the all the
> >> appropriate files. Including the cacerts file. That does not seem
> >> to happen. What is the proper way of handling self-signed
> >> certificates you want tomcat to trust?
> >>
> >> Off topic but you are folks who might know: On a related note I
> >> have the same issue with Java applications not running in Tomcat
> >> that use the same file /etc/pki….java/cacerts. Am I
> >> understanding the PKI update process correctly? Am I putting the
> >> self-signed certificate pem format file in the correct place?
> >>
> >> Darryl Baker, GSEC (he/him/his) Sr. System Administrator (...)
> >>
> >>
> > You can put your certificates and truststore wherever you want as
> > long as you tell Tomcat where they are in the conf/server.xml
> > configuration file when you configure the connector using them.
> >
> > Self-signed certificates should never be used on a production
> > server, they are not secure.
> What makes you say that?
>
> - -chris
> (...)
https://www.venafi.com/blog/self-signed-certificates-cyber-criminals-are-turning-strength-into-a-vulnerability
Never may be exaggerated in my post. But in general, you should avoid them.
But it all depends on your organization as well, mine is signing internal
certificates and managing to include itself in the browsers of all the
thousands employees. In a small business, it may not be possible and the
number of self-signed certificates may be low. In our organization, in the
past we have seen people setting up their own self-signed certificates with
too short keys to be secured by today's standards.
Regards,
-----------------
Daniel Savard
Re: [OT] Red Hat / CentOS specific question about certificates
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Daniel,
On 8/28/20 20:46, Daniel Savard wrote:
> Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
> darryl.baker@northwestern.edu> a écrit :
>
>> I am having an issue that I don’t understand. On RHEL6/CentOS
>> and earlier my predecessors would put self-signed certificates
>> they wanted to trust in /etc/pki/ca-trust/extracted/java/cacerts
>> and it was good for the life of the machine. On RHEL7 and I
>> assume CentOS7 that file is part of a package that is getting
>> updated as part of the regular patches. That wipes out our
>> self-signed certificates. The way I understand the directions
>> from Red Hat we should put the certificate in pem format in the
>> directory /etc/pki/ca-trust/source/anchors and run
>> update-ca-trust extract and that will update the all the
>> appropriate files. Including the cacerts file. That does not seem
>> to happen. What is the proper way of handling self-signed
>> certificates you want tomcat to trust?
>>
>> Off topic but you are folks who might know: On a related note I
>> have the same issue with Java applications not running in Tomcat
>> that use the same file /etc/pki….java/cacerts. Am I
>> understanding the PKI update process correctly? Am I putting the
>> self-signed certificate pem format file in the correct place?
>>
>> Darryl Baker, GSEC (he/him/his) Sr. System Administrator (...)
>>
>>
> You can put your certificates and truststore wherever you want as
> long as you tell Tomcat where they are in the conf/server.xml
> configuration file when you configure the connector using them.
>
> Self-signed certificates should never be used on a production
> server, they are not secure.
What makes you say that?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NE5wACgkQHPApP6U8
pFg57BAAl6VNkfGacih8/Uxn1tiyEbDkGAvcFpxbJkhcS1q4yTR171cGaKE50z1l
1GIWiiRdTdFCwI3SlCdQySKDZa4kCDPscv24zcPAIhVJ/1WKJ9PC/mLFZuRzR+3R
u2yYb5tUFcG7rESOf2WWgdB9uQrd/WMigr6qaLYIZFdOSKJ1xT1ujMMNUrFzleUw
FveFimPKg7MkMgCYKJWmH28dUKOICIGdL2hmq7gAsT161XCwFVcjHRT/lKRpnIlD
Mg1KTG6qTxMXSyBI4IopA8VRWAdjM6JaTyD65q4jjyeKTglklzmnU3WhFO4F1Jl2
vFlimBs0aNoRmNIuFfvQGyf5u7DKAdSYqrFk44atZQ2MNw5+Z6EDCtelLT/rneTf
xyYTkwqKgt7MRngTsJZ5w8T7exd7ZjhFSnwAs4ekohbh9sUTsd0DadTM6XbGsacL
p4c5aHrV9yYrye3RSfTEbwOr5FWR1G0VIMgONKdZA+BgNhm9CqdtoT04DA0iRY++
DskueqaKKEzEwV3P4/NYFKGj2nKtTMpYfrB6IUFghjMs/z29PYLgVVk/WVIEbLan
w3Er4oa/6r3C1ltq3EevvMbthww4nMf/cZqMRpG8ilIR4wn7t+IqfBGTJN9Ox4pj
Ik3pdWXw+5XoVaOqafUfhzc5Q1n6XSnTB5/yZifDhnsz/jzELIM=
=4pHT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Red Hat / CentOS specific question about certificates
Posted by Daniel Savard <da...@gmail.com>.
Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
darryl.baker@northwestern.edu> a écrit :
> I am having an issue that I don’t understand. On RHEL6/CentOS and earlier
> my predecessors would put self-signed certificates they wanted to trust in
> /etc/pki/ca-trust/extracted/java/cacerts and it was good for the life of
> the machine. On RHEL7 and I assume CentOS7 that file is part of a package
> that is getting updated as part of the regular patches. That wipes out our
> self-signed certificates. The way I understand the directions from Red Hat
> we should put the certificate in pem format in the directory
> /etc/pki/ca-trust/source/anchors and run update-ca-trust extract and that
> will update the all the appropriate files. Including the cacerts file. That
> does not seem to happen. What is the proper way of handling self-signed
> certificates you want tomcat to trust?
>
> Off topic but you are folks who might know:
> On a related note I have the same issue with Java applications not running
> in Tomcat that use the same file /etc/pki….java/cacerts. Am I understanding
> the PKI update process correctly? Am I putting the self-signed certificate
> pem format file in the correct place?
>
> Darryl Baker, GSEC (he/him/his)
> Sr. System Administrator
> (...)
>
>
You can put your certificates and truststore wherever you want as long as
you tell Tomcat where they are in the conf/server.xml configuration file
when you configure the connector using them. Self-signed certificates
should never be used on a production server, they are not secure. It is up
to you to handle the certificates when they expire unless you have some
other automated way to renew them. Normally, the cacerts file distributed
with Java is a JKS formatted trust store and the certificates it contains
will eventually expire. That's why when Java is updated you may get an
updated cacerts file as well. If you put your own certificates in that file
and it gets updated when Java is updated, obviously you will lost your
certificates. Just make a copy and put your certificates in the copy. In
fact, you may not need the original file at all if only self-signed
certificates are involved. All the certifications authorities in the file
are then useless to you.
Regards,
-----------------
Daniel Savard