As a CentOS Sysadmin, I want to be able to generate node x509 certs without having to enroll them into IPA, due to security concerns (we just need x509 cert, nothing else).

[puiterwijk]

What security concerns would you see by creating the node in IPA? By default they get nothing, unless you grant them specific credentials to access things.

[arrfab]

It would be good to get notifications about this git repo, and not discovering it by accident .. and so participating in the thread, and hopefully get notifications

It was agreed that CentOS nodes will not be in IPA, so no :)

[relrod]

@arrfab you can 'watch' the repo and get notifications. @puiterwijk probably knows more about the x509 requirements here than I do, so any insight is appreciated.

[sfinn85]

@abompard do we need more insight on this for sprint planning tomorrow?

[abompard]

Yeah, @relrod's comment still stands. @arrfab , @puiterwijk , any idea?

[puiterwijk]

@abompard @relrod So, after discussing with @arrfab, we came to the conclusion that their problems are with ipa-client. You can actually register the system (and make it available for x509 certs and everything) without installing ipa-client on the system, which would alleviate their problems. So I think this ticket can be closed.

[arrfab]

We need a way to have the x509 certs generated through dogtag/IPA, and retrieved, so that ansible can (re)configure our nodes, including koji builders. Failure to have such feature rolled-in would be considered a blocker for CentOS Stream, as builders are using that intensively :-)

[arrfab]

@puiterwijk is also right (as always) : we can't have the CentOS nodes enrolled directly into IPA, and so no "ipa-client" on our nodes for now, so we'll just (as we do for existing FAS), consider IPA a "user/group DB" that will be used to grant access through openid/openidc for various services. But nodes RBAC will be managed by ansible

[relrod]

@abompard so the work here is figuring out, assuming that a node is "enrolled" (without having IPA client on it) how to call the IPA certificate generation API endpoint in the right way to generate the kinds of certs they need. This is something we'll likely need to work closely on with @arrfab and @puiterwijk both, because they know more about both: the requirements there and how PKI works, than probably anybody on the current AAA team including myself.

[sfinn85]

Sprint planning 3 update:

Insight needed from CentOS Team to move this forward and will need some help from CentOS team. Not pulled into Sprint 3 for now, we may include it mid sprint if we have the capacity.

[sfinn85]

Adding notes from email from Fabian 2/6/20

Our koji builders (including for CentOS Stream, but not only those) need TLS auth and so we need to :

• generate nodes certificates from IPA/Dogtag
• have users generate those as they do with FAS (so calling the /dogencert URL for fas)
• have IPA/Security regenerate automatically.CRL when users are disabled or when the previous cert was revoked (we load those to ensure that someone disabled isn't able to touch service anymore)

[sfinn85]

Fabian and Aurélien possibly catching up on this tomorrow

[abompard]

As I understand it at the moment, Securitas has to provide a new endpoint that :

• will allow upload of a Certificate Signing Request
• will call the IPA cert-request endpoint with this CSR and return the corresponding signed certificate back to the caller
• is open to any authenticated user (and would use that user's session to do the API call).

Here are a few things that I'm not sure of:

• according to the IPA docs, kerberos principals must be created before we request a signed cert. Do we want to or need to?
• does this sound sane from a security point of view?

I'd love to have opinions on this process from people who know how things should be done with FreeIPA (@tiran , @puiterwijk ?). Thanks!

[arrfab]

Well, Securitas would require the user to be authenticated to send the CSR, but it would reuse his token to then call the IPA endpoint to sign CSR with the CA from dogtag/IPA. But any authenticated/validated user can request a cert to be signed by IPA, that's what I meant :)

[abompard]

Thanks, I'll correct my comment.

[tiran]

What kind of certificate do you want to generate? IPA enforces additional restrictions. A user can only request certificates for her/his own user name. A host or service can only request server certificates for their own host name/IP address. Additionally it is possible to delegate management (ipa host-add-managedby).

I recommend that you enroll the host and create services for CentOS machines, too. This will not only create all necessary entries in IPA. You also get additional features like automated cert request and renewal with certmonger.

[arrfab]

@tiran we need nodes/users certificates mainly for Koji, and that was part of the requirements list when AAA started. If there is a way to enroll virtually nodes in IPA without having those really part of IPA network (so no ipa* pkg installled on those nodes), and that an admin can request those nodes certificates to then distribute those through configmanagement (ansible), that'd do it

With FAS, users can request/renew user cert through call to http:///dogencert. For nodes, we had a custom wrapper script on the FAS node itself, that was using the CA to generate/sign CSR for nodes (nowhere to be seen in FAS, as there is no concept of node/host in FAS)

[tiran]

Yes, it is possible to create host and service entries without enrolling the host or service with ipa-client-install. You also need to bypass some policy checks, too.

@frasertweedale is our expert for certificate related policies and permissions. Fraser, please advise.

[frasertweedale]

The best approach is to create the host entries. As @tiran says, you do not need to have a such a host enrolled in IPA.

It is likely that the default profile, caIPAserviceCert, is appropriate for your use case, and therefore the default CA ACL hosts_services_caIPAserviceCert can be used (i.e. there is nothing more to configure w.r.t. CA ACLs). If you want to use a custom profile or issue the certs from a sub-CA, you'll have to (a) create the profile and/or sub-CA and (b) create a CA ACL that allows certificates to be issued to the hosts (using a hostgroup is recommended) with the indicated profile and CA.

Finally, in order to request the certificate, the operator principal (i.e. the principal executing the ipa cert-request command needs write access to the userCertificate attribute of the subject principal. If you use Certmonger to request and manage the certificates, the operator will be the host principal of the machine on which certmonger is running, and you can use the host/service managedby attribute to allow one host to write the userCertificate attribute of another host or service. If a user principal will be used to request the certificates, you will need to explicitly create the permissions.

[abompard]

Thanks a lot @tiran and @frasertweedale Quick question on the side for @arrfab , how do you currently authenticate to the FAS endpoint?

[arrfab]

@abompard : can you elaborate ? for the node cert we don't, as FAS doesn't support that at all, so , as mentioned on the previous comment, we (and Fedora was doing the same before) have (as sysadmin) a shell directly on FAS node with CA where we generate those nodes certs. Other requirement btw : for CentOS Stream (and so mbox, because it runs in openshift) , we need SANs extensions through the cert-request too

[abompard]

OK let me see if I got it straight. Could this work for you @arrfab :

• we (or you?) declare the hosts entries in IPA but don't enroll them
• the machine where you have your ansible repo can have the ipa client installed (but not the nodes, that part is understood)
• we set the managedby attribute on the node hosts in LDAP to the "ansible" machine
• from that machine, you can generate CSRs and submit them to IPA using the ipa cert-request command for the node hosts, retrieve them locally and store them in your ansible repo
• you use ansible to distribute those certs to the nodes
• if you run certmonger on the ansible host, it can also regenerate those certs when they expire

Could that work?

[arrfab]

Well, something like that, as yes, we were told that we'd have admin privs in IPA (as it's a shared instance for Fedora and CentOS) ;-) We can have a node (but not the ansible management station) that can , on behalf of the nodes for which we want to have certs, request such certificates, and we can distribute those through Ansible later.

That would work for the nodes certs, and Securitas portal (or "new-name-to-be-found-because-naming-is-hard" ;-) ) should still provide an endpoint for a yet-to-be-written-cli-tool so that end users can also request a user certificates (I guess that one python client generating locally private key - if not existing yet - and creating CSRs , to be sent to securitas, itself forwarding to IPA API endpoint once authenticated, and then back with .crt back to requester would work)

[sfinn85]

Follow up with Fabian for further clarity on this, do we need to do anything from our side

[abompard]

Access to IPA from the CentOS sysadmins will solve this issue, and the packager workflow is tracked in fedora-infra/fasjson#28. Closing this one