2:13 a.m.
If you are of the types who like tinkering, here is a way to restrict
CA certificates in your Fedora on specific domains. Currently limited
to gnutls applications.
http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html
regards,
Nikos
3:24 a.m.
On 06/03/2016 09:13 AM, Nikos Mavrogiannopoulos wrote:
If you are of the types who like tinkering, here is a way to
restrict
CA certificates in your Fedora on specific domains. Currently limited
to gnutls applications.
http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates.html
Is there also a way to do the opposite, that is, list which CAs are
permitted to issue certificates for certain parts of the DNS tree?
Thanks,
Florian
6:52 a.m.
On Fri, 2016-06-03 at 10:24 +0200, Florian Weimer wrote:
On 06/03/2016 09:13 AM, Nikos Mavrogiannopoulos wrote:
>
> If you are of the types who like tinkering, here is a way to
> restrict
> CA certificates in your Fedora on specific domains. Currently
> limited
> to gnutls applications.
>
> http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates
> .html
Is there also a way to do the opposite, that is, list which CAs are
permitted to issue certificates for certain parts of the DNS tree?
If your question is whether it is doable, then the answer is yes. One
would need to traverse all existing certificates in the trust module
and use the name constraints extension. In terms of gnutls API you'd
probably like to use call gnutls_x509_crt_import_url() with
the GNUTLS_PKCS11_OBJ_FLAG_OVERWRITE_TRUSTMOD_EXT flag on all the
certificate objects in the trust module, and sort their name
constraints. There is no tool for that though.
However, I'd bet that most CAs in that list have no constraints.
regards,
Nikos
6:54 a.m.
On 06/03/2016 01:52 PM, Nikos Mavrogiannopoulos wrote:
On Fri, 2016-06-03 at 10:24 +0200, Florian Weimer wrote:
> On 06/03/2016 09:13 AM, Nikos Mavrogiannopoulos wrote:
>>
>> If you are of the types who like tinkering, here is a way to
>> restrict
>> CA certificates in your Fedora on specific domains. Currently
>> limited
>> to gnutls applications.
>>
>> http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certificates
>> .html
> Is there also a way to do the opposite, that is, list which CAs are
> permitted to issue certificates for certain parts of the DNS tree?
If your question is whether it is doable, then the answer is yes. One
would need to traverse all existing certificates in the trust module
and use the name constraints extension. In terms of gnutls API you'd
probably like to use call gnutls_x509_crt_import_url() with
the GNUTLS_PKCS11_OBJ_FLAG_OVERWRITE_TRUSTMOD_EXT flag on all the
certificate objects in the trust module, and sort their name
constraints. There is no tool for that though.
Sorry, I didn't realize that my question was worded ambiguously.
Let me rephrase it: Is it possible to express that only the Red Hat
internal CA may issue certificates under *.corp.redhat.com, and no other
CAs may issue certificates for this subtree?
Thanks,
Florian
7:30 a.m.
On Pá, 2016-06-03 at 13:54 +0200, Florian Weimer wrote:
On 06/03/2016 01:52 PM, Nikos Mavrogiannopoulos wrote:
>
> On Fri, 2016-06-03 at 10:24 +0200, Florian Weimer wrote:
> >
> > On 06/03/2016 09:13 AM, Nikos Mavrogiannopoulos wrote:
> > >
> > >
> > > If you are of the types who like tinkering, here is a way to
> > > restrict
> > > CA certificates in your Fedora on specific domains. Currently
> > > limited
> > > to gnutls applications.
> > >
> > > http://nmav.gnutls.org/2016/06/restricting-scope-of-ca-certific
> > > ates
> > > .html
> > Is there also a way to do the opposite, that is, list which CAs
> > are
> > permitted to issue certificates for certain parts of the DNS
> > tree?
> If your question is whether it is doable, then the answer is yes.
> One
> would need to traverse all existing certificates in the trust
> module
> and use the name constraints extension. In terms of gnutls API
> you'd
> probably like to use call gnutls_x509_crt_import_url() with
> the GNUTLS_PKCS11_OBJ_FLAG_OVERWRITE_TRUSTMOD_EXT flag on all the
> certificate objects in the trust module, and sort their name
> constraints. There is no tool for that though.
Sorry, I didn't realize that my question was worded ambiguously.
Let me rephrase it: Is it possible to express that only the Red Hat
internal CA may issue certificates under *.corp.redhat.com, and no
other
CAs may issue certificates for this subtree?
Not in the terms of stapled extensions - as the extensions would have
to be stapled onto some concrete certificates. You would have to
basically create stapled extensions for every CA in your trusted list
except for the Red Hat internal CA. And if any additional CA is added
to the trusted list, it would have to get this stapled extension too.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
8:06 a.m.
On Fri, 2016-06-03 at 14:30 +0200, Tomas Mraz wrote:
> Sorry, I didn't realize that my question was worded
ambiguously.
>
> Let me rephrase it: Is it possible to express that only the Red
> Hat
> internal CA may issue certificates under *.corp.redhat.com, and no
> other
> CAs may issue certificates for this subtree?
Not in the terms of stapled extensions - as the extensions would have
to be stapled onto some concrete certificates. You would have to
basically create stapled extensions for every CA in your trusted list
except for the Red Hat internal CA. And if any additional CA is added
to the trusted list, it would have to get this stapled extension too.
Well you could do that by stapling every other certificate than Red
Hat's with corp.redhat.com being on the excluded subtrees.
regards,
Nikos
8:14 a.m.
On Pá, 2016-06-03 at 15:06 +0200, Nikos Mavrogiannopoulos wrote:
On Fri, 2016-06-03 at 14:30 +0200, Tomas Mraz wrote:
>
> >
> > Sorry, I didn't realize that my question was worded ambiguously.
> >
> > Let me rephrase it: Is it possible to express that only the Red
> > Hat
> > internal CA may issue certificates under *.corp.redhat.com, and
> > no
> > other
> > CAs may issue certificates for this subtree?
> Not in the terms of stapled extensions - as the extensions would
> have
> to be stapled onto some concrete certificates. You would have to
> basically create stapled extensions for every CA in your trusted
> list
> except for the Red Hat internal CA. And if any additional CA is
> added
> to the trusted list, it would have to get this stapled extension
> too.
Well you could do that by stapling every other certificate than Red
Hat's with corp.redhat.com being on the excluded subtrees.
Yes, that's what I wrote above however that would not be very practical
as you would have to monitor the trusted list for additions and staple
them too once they are added.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
8:19 a.m.
On Fri, 2016-06-03 at 15:14 +0200, Tomas Mraz wrote:
> > Not in the terms of stapled extensions - as the extensions
would
> > have
> > to be stapled onto some concrete certificates. You would have to
> > basically create stapled extensions for every CA in your trusted
> > list
> > except for the Red Hat internal CA. And if any additional CA is
> > added
> > to the trusted list, it would have to get this stapled extension
> > too.
> Well you could do that by stapling every other certificate than Red
> Hat's with corp.redhat.com being on the excluded subtrees.
Yes, that's what I wrote above however that would not be very
practical
as you would have to monitor the trusted list for additions and
staple
them too once they are added.
Ah, correct. Indeed if ca-certificates is updated an adds new CAs these
will not be stapled. I have no idea whether p11-kit has some way to say
staple all certificates except that one.
regards,
Nikos
5:05 a.m.
On Friday 03 June 2016 15:14:23 Tomas Mraz wrote:
On Pá, 2016-06-03 at 15:06 +0200, Nikos Mavrogiannopoulos wrote:
> On Fri, 2016-06-03 at 14:30 +0200, Tomas Mraz wrote:
> > > Sorry, I didn't realize that my question was worded ambiguously.
> > >
> > > Let me rephrase it: Is it possible to express that only the Red
> > > Hat
> > > internal CA may issue certificates under *.corp.redhat.com, and
> > > no
> > > other
> > > CAs may issue certificates for this subtree?
> >
> > Not in the terms of stapled extensions - as the extensions would
> > have
> > to be stapled onto some concrete certificates. You would have to
> > basically create stapled extensions for every CA in your trusted
> > list
> > except for the Red Hat internal CA. And if any additional CA is
> > added
> > to the trusted list, it would have to get this stapled extension
> > too.
>
> Well you could do that by stapling every other certificate than Red
> Hat's with corp.redhat.com being on the excluded subtrees.
Yes, that's what I wrote above however that would not be very
practical as you would have to monitor the trusted list for additions
and staple them too once they are added.
well, if it is really needed, I don't see why we couldn't create some
kind of /etc/p11-kit.d directory that houses scripts that will do such
transform on certificates on package upgrade/downgrade/reinstall
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
2878
days inactive
2881
days old
security@lists.fedoraproject.org
8 comments
4 participants
participants (4)
-
Florian Weimer -
Hubert Kario -
Nikos Mavrogiannopoulos -
Tomas Mraz