New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refs #28924: Drop amqp key and truststore + generate Artemis client certs #275
Conversation
@@ -121,31 +118,15 @@ | |||
key_file => $client_key, | |||
cert_file => $client_cert, | |||
} ~> | |||
file { $amqp_store_dir: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should ensure it's absent to clean up after ourselves, but I don't recall if we can ensure directories are absent in Puppet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wondered about that. Should the puppet module clean this up or installer post install task clean this up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Normally I'd say Puppet but if Puppet can't clean up directories with the file
type then I'm ok with a post install task rather than an exec here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my googling you can do a regular file set to absent with recursive set to true. This just doesn't feel as clean. That weird line where sometimes we cleanup in the puppet module and sometimes we use the puppet module to simply represent the state and the installer does cleanup. I thought we were universally doing the latter. Its hard to know which way to go.
Seeing this:
So the subsequent keytool command fails since -destkeystore is missing |
@ehelms just pinging to ensure you saw my last update 🏓 |
fdf0018
to
64867f1
Compare
12f26a8
to
b598214
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK, leaving it open so it can be merged together with the candlepin change.
I did some testing and was able to connect with SSL client auth from Katello to Artemis. I basically followed the steps here, extracted the client cert+key from the stores, and used them to connect. Seems like we should be able to approximate that here, and let me know if I can provide any more detail. |
@jturel Apologies, I'm not following what the action item is regarding server and client keystores. |
I need my own clarification then :) The Or is it for Candlepin to use? If so, Candlepin is connecting directly to the embedded artemis without SSL since it's running within the same JVM which means it's not necessary, unless you're thinking forward to candlepin connecting to an external Artemis |
Ahh yes. This client certificate is being added to the keystore/truststore so that it can be used by Katello. The client certificate is already deployed to the system in a place that Katello can consume it. This change is just ensuring its in the truststore. We abuse keystore/truststore by creating one and using it for both. /etc/pki/katello/certs/java-client.crt |
manifests/candlepin.pp
Outdated
@@ -31,6 +28,8 @@ | |||
} | |||
|
|||
$java_client_cert_name = 'java-client' | |||
$artemis_alias = 'artemis-client' | |||
$artemis_client_dn = "C=${city}, ST=${state}, O=candlepin, OU=${org_unit}, CN=${cname}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the CN should be $hostname rather than $cname
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be safe, I think this is correct. See https://github.com/theforeman/puppet-certs/pull/275/files#diff-0a129cc5a540f220caade2da4fc3229bR37
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, well here's the contents of the file:
katelloUser=C=Raleigh, ST=North Carolina, O=candlepin, OU=SomeOrgUnit, CN=[]
Hard to discern what you wanted me to see at that URL..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh, yea, I see now how this gets handled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to hostname, I forget cname is additional cnames to add.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In SSL you have Common Name
(cn
) and subject Alternative Name
(subjectAltName
). cname
is DNS terminology.
7d3e549
to
2ef13b0
Compare
manifests/candlepin.pp
Outdated
@@ -31,6 +28,8 @@ | |||
} | |||
|
|||
$java_client_cert_name = 'java-client' | |||
$artemis_alias = 'artemis-client' | |||
$artemis_client_dn = "C=${city}, ST=${state}, O=candlepin, OU=${org_unit}, CN=${hostname}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It actually seems like the order of these matters.... (most specific -> least specific?)
Should be like this: CN=localhost, OU=SomeOrgUnit, O=candlepin, ST=North Carolina, C=US
Note also that C is country, not city
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh yea, sorry you are right on the country.
I modeled this off of "C=US, ST=North Carolina, O=candlepin, OU=SomeOrgUnit, CN=dhcp-8-29-228.lab.eng.rdu2.redhat.com"
openssl x509 -noout -text -in /etc/pki/katello/certs/java-client.crt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All good. When I re-order them in login.config it prevents Katello from connecting with an auth failure 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK. works in prod and dev.
No description provided.