when *not* using -partial_chain
** Changed in: sssd (Ubuntu)
Status: New => In Progress
** Changed in: sssd (Ubuntu)
Assignee: (unassigned) => Marco Trevisan (Treviño) (3v1n0)
** Changed in: sssd (Ubuntu)
Importance: Undecided => High
--
You received this bug notification
Yeah, sure...
As per man page:
-partial_chain
Allow verification to succeed even if a complete chain cannot be
built to a self-signed trust-anchor,
provided it is possible to construct a chain to a trusted
certificate that might not be self-signed.
And you can test it
So, I've done some work on SSSD upstream to make this to happen:
https://github.com/SSSD/sssd/pull/5558
With that we'll just be able to set on upgraders the option
`certification_verification = partial_chain`, and this will just make
the SSSD's PEM ring to work as the NSS db used to work: and so
re conversion / upgrades => we should really find the full chain if we
can to inject it into openssl.
I'm not sure if there are any ways to force openssl to be happy with
trusted issuer without a full chain.
I would have thought there is a way to make openssl do that.
--
You received this bug
Re: certs.
Ideally we should be shipping a bundle of certificates, which are well
known roots of trust for smarcards. Aka the DOD, National ID
cards/passports, etc. In a new path locations.
Because the smartcard roots of trusts are not the same as for https://
connections.
But that's not
I think that is a long standing openssl bug that it demands full chains,
and more so it trips up not only when the chain is incomplete, but also
where there are extra chains, which are redundant; and if any of them
have untrusted certs, or certs of small sizes / old hashes (aka legacy
chains) it
> While this would technically work, it would be really bad news. This
would allow anyone with any user cert issued by a CA in the system wide
cert store (by any CA in the world) to be trusted and pass authorization
checks by p11_child. (Albeit, some directory attributes would have to
line up,
On Thu, Mar 18, 2021 at 02:14:23AM -, Karl Grindley wrote:
> I'll also comment, (and perhaps a bit of scope creap, but...) we've
> found a number of unfixed issues with sssd, specifically with PKINIT and
> LDAP optimizations. We're working with the upstream maintainers to help
> address
Karl, I'm the responsible for what it concerns this specific change and
so feel free to use me a reference for this (maybe ping me on IRC so we
can have some better interaction regarding the best solution we can
take).
However, the SSSD maintainer in ubuntu is Sergio Durigan Junior, so he's
the
I agree and concur.
Just need some checks here, as this is a pretty big change in behavior
for a mid-life LTS release.
That said, the new configuration is in line with RHEL8, and will help
reduce the configuration scope for a working solution.
I'll also comment, (and perhaps a bit of scope
Karl, thank you for the detailed writeup? This looks very useful. I'll
leave Marco to respond as he drove the change in question, but a couple
of less technical comments:
On Thu, Mar 18, 2021 at 01:16:28AM -, Karl Grindley wrote:
> I don't discourage this change, in fact, will help push along
> Karl, thank you for the detailed writeup?
That was intended to say:
Karl, thank you for the detailed writeup!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1919563
Title:
updated sssd with
So, if I didn't get it wrong, if we'd just use /etc/ssl/certs/ca-
certificates.crt as the SSSD pam certificate in such case would work?
I mean having this in /etc/sssd/sssd.conf
[pam]
pam_cert_db_path = /etc/ssl/certs/ca-certificates.crt
And then what was into /etc/sssd/pki/sssd_auth_ca_db.pem
To speak to real world assessment here - there's a big push across many
(US) gov't orgs and industry to deploy MFA. These requirements are not
new, but many have not been enforced due to lack of compliance
checks/certifications.
This is changing with new efforts in the US Gov't industry circles
Karl, thank you for your report.
We now need to decide an appropriate course of action here. An update to
sssd to revert the change is a possibility, but there's also risk there
that we will break users twice.
Do you have a deployment affected by this? How many other users might be
affected by
Could you maybe provide an example setup we can reuse to simulate such
scenario?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1919563
Title:
updated sssd with smart cards now brick systems without
** Information type changed from Private Security to Public
** Tags added: regression-update
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1919563
Title:
updated sssd with smart cards now brick
17 matches
Mail list logo
