Nathan
On 4/25/16 11:18 PM, Nathan Scott wrote:
Yep & will definitely help with getting a pmcd.feature.* metric in place
too, as that PMDA code uses those libpcp pmServerFeature interfaces too.
OK, This is done.
At the client end, regardless of whether or not pmproxy is in the mix,
if a CERT_REQD is received and the client was not invoked with
"PCP_SECURE_SOCKETS=enforce" should that be an error? Or should we try
to upgrade the connection?
I think an error would be OK, but I guess go with whichever behaviour makes
the most sense for your real-world use-case.
I created a new error type, and went that route. I think it makes the
most sense.
[...] /var/lib/pcp/config/nssdb would suit? Not sure.
I went with this location and it works for both pmproxy and pmcd, so
that is convenient.
No worries. I punted that this will be ready for next release, so added a
card in for 3.11.3 - feel free to move it somewhere else more appropriate,
if that sounds too soon. ( http://pcp.io/roadmap )
Yeah, thats my goal to get this finished up pretty soon.
I think the implementation is now done, pending a few questions and
cleanups below. Some docs and QA to still come once I iron these issues out.
See latest version here:
https://github.com/ubccr/pcp/tree/client_certs
Split diff to master:
https://github.com/ubccr/pcp/compare/master...ubccr:client_certs#files_bucket
I've tried to comment the code where I still had questions, but a few
notes below. Changes since the last go around:
1.
I realized that there needed to be a way to change the name of the
collector server certificate that pmcd and pmproxy used. The original
hardcoded "PCP Collector certificate" was causing problems when I tried
to setup multiple hosts to be monitored. After much debugging, it
appears that NSS enforces a 1:1 mapping between nickname and subject in
a certificate db. This is easy to enforce on a single host, but if I
create a "PCP Collector certificate" on multiple hosts and use a unique
subject for each, a remote pmclient that connects to both pmcds will
fail to import the second certificate with little indication as to why.
A new option to pmcd and pmproxy allows the (server) certificate name to
be specified. The default is to use the existing name.
2. The existing code forces a client to use $HOME/.pki/nssdb.
Especially for testing purposes, I found it useful to be able to change
this. There may be operational uses as well that I haven't though of.
So I added a PCP_SECURE_DB_PATH env var that clients could set.
3. A second component of the solution to Problem 1 above is to change
the name that is used when a client saves a server certificate. The
original code used the same "PCP Collector certificate". I changed it to
use the subject as the nickname to save. This is useful when monitoring
multiple clients. One, for the reasons above, this is another way to try
to ensure the cert will be saved properly. But also, If you end up with
multiple certs having the same nickname in your db, there is no easy way
to remove a specific one. If we can try to enforce a unique name, this
makes cert management much easier.
4. New functionality to allow pmproxy to pass through to a client that a
client cert is required by pmcd. It took me while to figure out the
handshaking protocol and there may be a couple checks that are not
required. I added notes to the code in these spots.
5. I believe there was a typo in the __pmSecureClientHandshake call for
pmproxy. As far as I could tell, the hostname passed in here should be
of the remote pmcd, not localhost. I believe all other uses of this
function behave that way. It seems to work either way but I think the
only use of this is by the SSL libraries to do hostname verification on
the certificate. If the local hostname is not needed, I believe the
whole local hostname generation code can go as well.
6. Finally, pmproxy needs to intercept the initial extended error pdu
that pmcd sends to the pmclient. I needed to use an internal libpcp
function here. For testing, just copied the function. Not sure what
the policy was on exporting this. Or if this should be wrapped as a new
exportable function from libpcp. If that would require a new pcp major
version, etc.
Thanks
Martins
|