Re: OpenSSL verify untrusted issue

>>   FreeRADIUS was configured with the root but not told to trust it for 
some reason.
FreeRADIUS is used to check client certificate provided by client against *limited 
set* of roots and intermediates provided by config.
This is intentionally limited to just a few certificates, rather than 
system-wide roots, so that when a client presents a certificate to a 
server, the server only accepts clients with certificate issued by specific 
chains of CAs (usually, enterprise self-signed CA)

For FreeRADIUS side, the client certificate is provided by client and the 
context is created using this code, as I assume. I cut many non-important 
lines from my point, and I'm not OpenSSL or FreeRADIUS pro.
What is FreeRADIUS missing about marking the certificates in store as 
trusted? 

ctx = SSL_CTX_new(SSLv23_method());
X509_STORE *store = X509_STORE_new(); X509_STORE_load_locations(store, conf
->ca_file, conf->ca_path)); 
SSL_CTX_set_cert_store(ctx, store);
verify_mode |= SSL_VERIFY_PEER;
verify_mode |= SSL_VERIFY_FAIL_IF_NO_PEER_CERT;
verify_mode |= SSL_VERIFY_CLIENT_ONCE;
SSL_CTX_set_verify(ctx, verify_mode, cbtls_verify);


суббота, 9 ноября 2024 г. в 19:01:18 UTC+3, Michael Wojcik: 

> > From: Aleksei “filimonic” Filimonov <[email protected]>
> > Sent: Saturday, 9 November, 2024 05:52
>
> > FreeRADIUS uses this code (below) and it shows in logs there is 1 cert is
> > untrusted according to X509_STORE_CTX_get_num_untrusted,
>
> This number is misleading; it does not count the first certificate in the 
> chain. See the documentation for X509_STORE_CTX_get_num_untrusted. That's 
> presumably because the first certificate is *assumed* to be untrusted; the 
> whole point of building a chain is to get from an untrusted certificate (a 
> claim of identity) to a trust anchor (a certificate that you *do* trust).
>
> > and outputs everything (2 certs) from X509_STORE_CTX_get0_untrusted 
> stack.
> > For start, It's hard to say if this "one untrusted cert" is the root or 
> the peer
>
> It's both.
>
> It's normal for the peer entity certificate to be untrusted. (If you 
> already trusted it, you'd essentially not be using PKI at all; all the 
> participating peers would already have copies or other verifiers for one 
> another's certificates, and there would be no higher authority.)
>
> The problem, as I wrote in my previous note, appears to be that FreeRADIUS 
> does not trust the root. I can't tell where it got the root from -- if the 
> peer sent it as part of its chain (that's allowed but often omitted), or if 
> FreeRADIUS was configured with the root but not told to trust it for some 
> reason, or if there's something else at work here which is not obvious. 
> Again, I don't know how FreeRADIUS is configured.
>
> --
> Michael Wojcik
> ================================
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 
> 02451 ■ Main Office Toll Free Number: +1 855.577.4323 <(855)%20577-4323>
> Contact Customer Support: 
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
> http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy - 
> http://www.rocketsoftware.com/company/legal/privacy-policy
> ================================
>
> This communication and any attachments may contain confidential 
> information of Rocket Software, Inc. All unauthorized use, disclosure or 
> distribution is prohibited. If you are not the intended recipient, please 
> notify Rocket Software immediately and destroy all copies of this 
> communication. Thank you.
>

-- 
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/eb5205b4-af77-4d32-9b0a-e498e1a214a6n%40openssl.org.