Mock: how to get a client cert + key into the chroot?

Hi,

How do I get a client certificate + key into the mock chroot? Mock needs 
access to a repo which requires the client to send its certificate 
(nginx with ssl_verify_client on;).

If I copy the certificate and key to /etc/pki/tls/{certs,private} in the 
bootstrap directory then the chroot picks them up and the repo is available.

Is there a way to specify the client certificate + key in a config 
somewhere so they get picked up automatically?

Thanks!

Best,
Patrick

[Patrick Riehecky]

I believe you'll want to look at the bind mount options to put the cert
where your repo expects it.

https://fedoraproject.org/wiki/Mock/Plugin/BindMount

Pat

On Mon, 2021-11-15 at 18:41 +0100, [e-mail] wrote:
> Hi,
>
> How do I get a client certificate + key into the mock chroot? Mock
> needs 
> access to a repo which requires the client to send its certificate 
> (nginx with ssl_verify_client on;).
>
> If I copy the certificate and key to /etc/pki/tls/{certs,private} in
> the 
> bootstrap directory then the chroot picks them up and the repo is
> available.
>
> Is there a way to specify the client certificate + key in a config 
> somewhere so they get picked up automatically?
>
> Thanks!
>
> Best,
> Patrick
> _______________________________________________
> buildsys mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_...
>  
> List Guidelines:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_...
>  
> List Archives:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org...
>  
> Do not reply to spam on the list, report it:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Dinfr...

Hi Pat,

On 15-11-2021 19:38, Patrick Riehecky wrote:
> I believe you'll want to look at the bind mount options to put the cert
> where your repo expects it.
>
> https://fedoraproject.org/wiki/Mock/Plugin/BindMount

Thank you, I'll give that a try.

Best,
Patrick

[Miroslav Suchý]

Dne 15. 11. 21 v 18:41 [e-mail] napsal(a):
> Hi,
>
> How do I get a client certificate + key into the mock chroot? Mock needs access to a repo which requires the client to 
> send its certificate (nginx with ssl_verify_client on;).
>
> If I copy the certificate and key to /etc/pki/tls/{certs,private} in the bootstrap directory then the chroot picks 
> them up and the repo is available.
>
> Is there a way to specify the client certificate + key in a config somewhere so they get picked up automatically?

Yes, there is a way:

https://rpm-software-management.github.io/mock/feature-gpg-and-ssl

Miroslav

Hi Miroslav,

On 15-11-2021 20:20, Miroslav Suchý wrote:
[snip]
> > Is there a way to specify the client certificate + key in a config 
> > somewhere so they get picked up automatically?
>
> Yes, there is a way:
>
> https://rpm-software-management.github.io/mock/feature-gpg-and-ssl

Thank you (both) for your feedback. And for mock. I could not get your 
nor Pat's suggestion to work with a self-signed certificate and key. So 
I came up with the attached patch. I'll be happy to create a PR/MR if 
this is something you would consider adding?

Quick explanation:

in /etc/mock/<your_config>.cfg add

config_opts['ssl_extra_certs'] = [
     '/etc/pki/tls/certs/client.crt', '/etc/pki/tls/certs/',
     '/etc/pki/tls/private/client.key', '/etc/pki/tls/private/'
     ...
]

Also add the required sslclientcert and sslclientkey options to your 
private repo config in the same file, e.g.:

[private]
name=My private repo
baseurl=https://example.org/repo/private/$releasever/$basearch/
module_hotfixes=true
enabled=1
sslclientcert=/etc/pki/tls/certs/client.crt
sslclientkey=/etc/pki/tls/private/client.key
sslcacert=...

When mock runs it will copy client.crt and client.key to their 
destination directories in both the bootstrap and final chroot so that 
dnf can send the client cert to the webserver (nginx: ssl_verify_client: 
on;) to get access.

Best,
Patrick

[Miroslav Suchý]

Dne 16. 11. 21 v 19:37 [e-mail] napsal(a):
> Thank you (both) for your feedback. And for mock. I could not get your nor Pat's suggestion to work with a self-signed 
> certificate and key.

Did you updated the ca-bundle.crt?

https://unix.stackexchange.com/a/445884/100010
> So I came up with the attached patch. I'll be happy to create a PR/MR if this is something you would consider adding?

PR is always welcomed. But before we add something new I will want to know why the current solution does not work.

Miroslav

Hi Miroslav,

Thank you for your feedback.

On 17-11-2021 11:28, Miroslav Suchý wrote:
> Dne 16. 11. 21 v 19:37 [e-mail] napsal(a):
> > Thank you (both) for your feedback. And for mock. I could not get your 
> > nor Pat's suggestion to work with a self-signed certificate and key.
>
> Did you updated the ca-bundle.crt?
>
> https://unix.stackexchange.com/a/445884/100010

I did not because AFAICT the ca-bundle is for CA certificates and not 
for a client (non-CA) certificate and key.

$ man update-ca-trust
update-ca-trust - manage consolidated and dynamic configuration of CA 
certificates and associated trust

I only see CA certificates mentioned in that manpage, not non-CA/client 
certificates and keys. On the host the ca-bundle.crt is public (0644) 
and I'd rather not put a client.key in there. IMHO this does not seem 
the appropriate place or mechanism for non-CA certificates.
> > So I came up with the attached patch. I'll be happy to create a PR/MR 
> > if this is something you would consider adding?
>
> PR is always welcomed. But before we add something new I will want to 
> know why the current solution does not work.

I guess it works but IMHO it's just not a proper solution to mix CAs 
with client certificates and keys.

Best,
Patrick

[Pavel Raiskup]

On Wednesday, November 17, 2021 12:08:27 PM CET [e-mail] wrote:
> Hi Miroslav,
>
> Thank you for your feedback.
>
> On 17-11-2021 11:28, Miroslav Suchý wrote:
> > Dne 16. 11. 21 v 19:37 [e-mail] napsal(a):
> > > Thank you (both) for your feedback. And for mock. I could not get your 
> > > nor Pat's suggestion to work with a self-signed certificate and key.
> >
> > Did you updated the ca-bundle.crt?
> >
> > https://unix.stackexchange.com/a/445884/100010
>
> I did not because AFAICT the ca-bundle is for CA certificates and not 
> for a client (non-CA) certificate and key.

You can get an inspiration from rhel chroots, where also client pem files are
used for DNF (curl) to authenticate against RHEL CDN:
https://github.com/rpm-software-management/mock/blob/d081bc113e3c6af9b801675...
Perhaps you can re-use that directory?

Still, the public certificate should go to the bundle, I tend to agree with
@msuchy.

Pavel
> $ man update-ca-trust
> update-ca-trust - manage consolidated and dynamic configuration of CA 
> certificates and associated trust
>
> I only see CA certificates mentioned in that manpage, not non-CA/client 
> certificates and keys. On the host the ca-bundle.crt is public (0644) 
> and I'd rather not put a client.key in there. IMHO this does not seem 
> the appropriate place or mechanism for non-CA certificates.
> > > So I came up with the attached patch. I'll be happy to create a PR/MR 
> > > if this is something you would consider adding?
> >
> > PR is always welcomed. But before we add something new I will want to 
> > know why the current solution does not work.
>
> I guess it works but IMHO it's just not a proper solution to mix CAs 
> with client certificates and keys.
>
> Best,
> Patrick
> _______________________________________________
> buildsys mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail].o...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

Hi Pavel,

Thank you for your feedback.

On 18-11-2021 10:17, Pavel Raiskup wrote:
> > I did not because AFAICT the ca-bundle is for CA certificates and not
> > for a client (non-CA) certificate and key.
>
> You can get an inspiration from rhel chroots, where also client pem files are
> used for DNF (curl) to authenticate against RHEL CDN:
> https://github.com/rpm-software-management/mock/blob/d081bc113e3c6af9b801675...
> Perhaps you can re-use that directory?

Sure, I could re-use /etc/pki/entitlement for non-entitlement 
certificates. But why put client certs & keys in an entitlement 
directory when you can put them in the obvious (and IMHO correct) location?

client.pem -> /etc/pki/tls/certs/
client.key -> /etc/pki/tls/private/
> Still, the public certificate should go to the bundle, I tend to agree with
> @msuchy.

I would agree if you were talking about a *CA* certificate? For non-CA 
certificates the ca-bundle is IMHO not the proper place.

If on RHEL & Fedora hosts these default locations are used:

CA certificates -> ca-bundle
RHEL entitlements -> /etc/pki/entitlement/
Public client/server certificates -> /etc/pki/tls/certs/
Private client/server certificates -> /etc/pki/tls/private/

then isn't it logical to copy that behavior into the chroot?

Best,
Patrick

[Pavel Raiskup]

On Thursday, November 18, 2021 1:35:29 PM CET [e-mail] wrote:
> Hi Pavel,
>
> Thank you for your feedback.
>
> On 18-11-2021 10:17, Pavel Raiskup wrote:
> > > I did not because AFAICT the ca-bundle is for CA certificates and not
> > > for a client (non-CA) certificate and key.
> >
> > You can get an inspiration from rhel chroots, where also client pem files are
> > used for DNF (curl) to authenticate against RHEL CDN:
> > https://github.com/rpm-software-management/mock/blob/d081bc113e3c6af9b801675...
> > Perhaps you can re-use that directory?
>
> Sure, I could re-use /etc/pki/entitlement for non-entitlement 
> certificates. But why put client certs & keys in an entitlement 
> directory when you can put them in the obvious (and IMHO correct) location?
>
> client.pem -> /etc/pki/tls/certs/
> client.key -> /etc/pki/tls/private/

You wrote that your "mock needs an access to repos".  So I naturally thought
that we are talking about something like the entitlement key+cert pair (which is
quite a new thing in mock anyways, and the only chroot using that is RHEL, and
... /etc/pkg/entitlement is not a bad place).   Though ....
> > Still, the public certificate should go to the bundle, I tend to agree with
> > @msuchy.
>
> I would agree if you were talking about a *CA* certificate? For non-CA 
> certificates the ca-bundle is IMHO not the proper place.
>
> If on RHEL & Fedora hosts these default locations are used:
>
> CA certificates -> ca-bundle
> RHEL entitlements -> /etc/pki/entitlement/
> Public client/server certificates -> /etc/pki/tls/certs/
> Private client/server certificates -> /etc/pki/tls/private/
>
> then isn't it logical to copy that behavior into the chroot?

... if for any reason you can't or don't want to use that, it's OK - I think
patches are welcome, and I bet that the current mock support is really RHEL-only
oriented, meaning that smaller or bigger patch would be needed anyway ;)

Happy hacking!
Pavel
> Best,
> Patrick
> _______________________________________________
> buildsys mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail].o...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

On 18-11-2021 14:50, Pavel Raiskup wrote:
> On Thursday, November 18, 2021 1:35:29 PM CET [e-mail] wrote:

[snip]
> You wrote that your "mock needs an access to repos".  So I naturally thought
> that we are talking about something like the entitlement key+cert pair (which is
> quite a new thing in mock anyways, and the only chroot using that is RHEL, and
> ... /etc/pkg/entitlement is not a bad place).   Though ....

Heh now I see your point. I was not talking about RHEL entitlements. I 
totally agree that /etc/pki/entitlement/ is not a bad place for RHEL 
repo entitlement certificates. It's a great place :-)

[snip]
> > If on RHEL & Fedora hosts these default locations are used:
> >
> > CA certificates -> ca-bundle
> > RHEL entitlements -> /etc/pki/entitlement/
> > Public client/server certificates -> /etc/pki/tls/certs/
> > Private client/server certificates -> /etc/pki/tls/private/
> >
> > then isn't it logical to copy that behavior into the chroot?
>
> ... if for any reason you can't or don't want to use that, it's OK - I think
> patches are welcome, and I bet that the current mock support is really RHEL-only
> oriented, meaning that smaller or bigger patch would be needed anyway ;)

My use case is that some (non-RHEL) repos are private and require a 
client certificate to gain access. That's why I wrote the patch.

Works: Mock -> public repos like Fedora & CentOS
Works: Mock -> RHEL repos requiring an entitlement
Works: Mock + patch -> public and private repos via cert & key in 
standard locations

What should be different ("smaller or bigger") about the patch? I'll be 
happy to try.
> Happy hacking!

Thanks :-)

Best,
Patrick

[Pavel Raiskup]

On Thursday, November 18, 2021 4:41:34 PM CET [e-mail] wrote:
> On 18-11-2021 14:50, Pavel Raiskup wrote:
> > On Thursday, November 18, 2021 1:35:29 PM CET [e-mail] wrote:
>
> [snip]
> > You wrote that your "mock needs an access to repos".  So I naturally thought
> > that we are talking about something like the entitlement key+cert pair (which is
> > quite a new thing in mock anyways, and the only chroot using that is RHEL, and
> > ... /etc/pkg/entitlement is not a bad place).   Though ....
>
> Heh now I see your point. I was not talking about RHEL entitlements. I 
> totally agree that /etc/pki/entitlement/ is not a bad place for RHEL 
> repo entitlement certificates. It's a great place :-)
>
> [snip]
> > > If on RHEL & Fedora hosts these default locations are used:
> > >
> > > CA certificates -> ca-bundle
> > > RHEL entitlements -> /etc/pki/entitlement/
> > > Public client/server certificates -> /etc/pki/tls/certs/
> > > Private client/server certificates -> /etc/pki/tls/private/
> > >
> > > then isn't it logical to copy that behavior into the chroot?
> >
> > ... if for any reason you can't or don't want to use that, it's OK - I think
> > patches are welcome, and I bet that the current mock support is really RHEL-only
> > oriented, meaning that smaller or bigger patch would be needed anyway ;)
>
> My use case is that some (non-RHEL) repos are private and require a 
> client certificate to gain access. That's why I wrote the patch.
>
> Works: Mock -> public repos like Fedora & CentOS
> Works: Mock -> RHEL repos requiring an entitlement
> Works: Mock + patch -> public and private repos via cert & key in 
> standard locations
>
> What should be different ("smaller or bigger") about the patch? I'll be 
> happy to try.

Ah, I missed the patch.  Can you please provide a pull-request with that?
We can go through a formal review...

Pavel
> > Happy hacking!
>
> Thanks :-)
>
> Best,
> Patrick
> _______________________________________________
> buildsys mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail].o...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure