Windows Machines not Validating Cert
I'm using EAP-TTLS. When generating the production certs I know it says in the readme file that all client machines need to have the root CA installed for it to work, but that doesn't seem to be the case in my setup. If I connect from a windows 11 machine I get a notification asking if I am happy with the certificate information for the server that I am connecting to, but I haven't got the root CA cert installed on my machine. I then just accept the notification and it allows me to connect. Even after installing it nothing really changed. Would this indicate that something is set up wrong with the RADIUS server? The debug logs confirm that a TLS handshake is complete. Many thanks!
On Nov 6, 2024, at 10:20 AM, FreeRAD <yetifreerad@gmail.com> wrote:
I'm using EAP-TTLS. When generating the production certs I know it says in the readme file that all client machines need to have the root CA installed for it to work, but that doesn't seem to be the case in my setup. If I connect from a windows 11 machine I get a notification asking if I am happy with the certificate information for the server that I am connecting to, but I haven't got the root CA cert installed on my machine. I then just accept the notification and it allows me to connect. Even after installing it nothing really changed.
The certificate chain is sent to the client as part of the TLS connection setup. So presumably the Windows machine is caching the cert. i.e,. if it asks you "is the cert OK", and you say "yes", then that causes the cert / root CA to pass. That explains why it works.
Would this indicate that something is set up wrong with the RADIUS server?
No. It indicates that you configured Windows to accept the server cert / root CA. So it accepts them. Alan DeKok.
Hi Alan, Thank you for the information. I've noticed when authenticating via PEAP you can force Windows to authenticate the Root CA but EAPTTLS doesn't seem to have the option. On Wed, Nov 6, 2024 at 10:24 AM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 6, 2024, at 10:20 AM, FreeRAD <yetifreerad@gmail.com> wrote:
I'm using EAP-TTLS. When generating the production certs I know it says
in
the readme file that all client machines need to have the root CA installed for it to work, but that doesn't seem to be the case in my setup. If I connect from a windows 11 machine I get a notification asking if I am happy with the certificate information for the server that I am connecting to, but I haven't got the root CA cert installed on my machine. I then just accept the notification and it allows me to connect. Even after installing it nothing really changed.
The certificate chain is sent to the client as part of the TLS connection setup. So presumably the Windows machine is caching the cert.
i.e,. if it asks you "is the cert OK", and you say "yes", then that causes the cert / root CA to pass. That explains why it works.
Would this indicate that something is set up wrong with the RADIUS server?
No. It indicates that you configured Windows to accept the server cert / root CA. So it accepts them.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi Alan, Just one other quick thing, I've noticed that I can see an EAP-Message Attribute in my 'Access-Accept' message back from the server but I was under the impression that the below config in the inner-tunnel config file should stop this. Especially given that it stops me seeing any of the other attributes (apart from User-Name but that was purposefully left in for account purposes). *update reply { User-Name !* ANY Message-Authenticator !* ANY EAP-Message !* ANY Proxy-State !* ANY MS-MPPE-Encryption-Types !* ANY MS-MPPE-Encryption-Policy !* ANY MS-MPPE-Send-Key !* ANY MS-MPPE-Recv-Key !* ANY Tunnel-Type !* ANY Tunnel-Medium-Type !* ANY Tunnel-Private-Group-Id !* ANY }* On Wed, Nov 6, 2024 at 10:39 AM FreeRAD <yetifreerad@gmail.com> wrote:
Hi Alan,
Thank you for the information. I've noticed when authenticating via PEAP you can force Windows to authenticate the Root CA but EAPTTLS doesn't seem to have the option.
On Wed, Nov 6, 2024 at 10:24 AM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 6, 2024, at 10:20 AM, FreeRAD <yetifreerad@gmail.com> wrote:
I'm using EAP-TTLS. When generating the production certs I know it says
in
the readme file that all client machines need to have the root CA installed for it to work, but that doesn't seem to be the case in my setup. If I connect from a windows 11 machine I get a notification asking if I am happy with the certificate information for the server that I am connecting to, but I haven't got the root CA cert installed on my machine. I then just accept the notification and it allows me to connect. Even after installing it nothing really changed.
The certificate chain is sent to the client as part of the TLS connection setup. So presumably the Windows machine is caching the cert.
i.e,. if it asks you "is the cert OK", and you say "yes", then that causes the cert / root CA to pass. That explains why it works.
Would this indicate that something is set up wrong with the RADIUS server?
No. It indicates that you configured Windows to accept the server cert / root CA. So it accepts them.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 06/11/2024 11:42, FreeRAD wrote:
Just one other quick thing, I've noticed that I can see an EAP-Message Attribute in my 'Access-Accept' message back from the server but I was under the impression that the below config in the inner-tunnel config file should stop this. Especially given that it stops me seeing any of the other attributes (apart from User-Name but that was purposefully left in for account purposes).
If you don't send the final EAP-Message back then the EAP Success message won't arrive and the login will be denied. I can't see how that can be a good thing. -- Matthew
Hi Matthew, I agree I just found it odd that it was part of the "under no circumstances should these be in the outer reply" list of attributes in the inner-tunnel config but it is present there. For example I can't see the MS-MPPE attributes which is good but I can see the EAP-Message one even though they're part of the same list. Thanks! On Wed, Nov 6, 2024 at 11:51 AM Matthew Newton via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
On 06/11/2024 11:42, FreeRAD wrote:
Just one other quick thing, I've noticed that I can see an EAP-Message Attribute in my 'Access-Accept' message back from the server but I was under the impression that the below config in the inner-tunnel config file should stop this. Especially given that it stops me seeing any of the other attributes (apart from User-Name but that was purposefully left in for account purposes).
If you don't send the final EAP-Message back then the EAP Success message won't arrive and the login will be denied.
I can't see how that can be a good thing.
-- Matthew - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 6, 2024, at 11:56 AM, FreeRAD <yetifreerad@gmail.com> wrote:
I agree I just found it odd that it was part of the "under no circumstances should these be in the outer reply" list of attributes in the inner-tunnel config but it is present there. For example I can't see the MS-MPPE attributes which is good but I can see the EAP-Message one even though they're part of the same list.
No, they're not. You're misunderstanding the debug output. You're confusing the inner reply with the outer reply. They're not the same. Alan DeKok.
Hi Alan, Apologies I guess I misunderstood that section. So rather than it removing these attributes from the outer reply altogether, it just means that if the attributes are present in the inner reply and they are also listed here, they aren't copied to the outer reply. However, those attributes may still be present in the outer reply just not the exact ones that were in the inner reply. Is that more along the right lines? On Wed, Nov 6, 2024 at 12:00 PM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 6, 2024, at 11:56 AM, FreeRAD <yetifreerad@gmail.com> wrote:
I agree I just found it odd that it was part of the "under no circumstances should these be in the outer reply" list of attributes in the inner-tunnel config but it is present there. For example I can't see the MS-MPPE attributes which is good but I can see the EAP-Message one even though they're part of the same list.
No, they're not. You're misunderstanding the debug output. You're confusing the inner reply with the outer reply. They're not the same.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Makes sense, thank you On Wed, Nov 6, 2024 at 12:17 PM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 6, 2024, at 12:12 PM, FreeRAD <yetifreerad@gmail.com> wrote:
Is that more along the right lines?
Yes. That's exactly what the configuration does.
Alan DeKok,
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 6, 2024, at 11:42 AM, FreeRAD <yetifreerad@gmail.com> wrote:
Just one other quick thing, I've noticed that I can see an EAP-Message Attribute in my 'Access-Accept' message back from the server
That is how it works.
but I was under the impression that the below config in the inner-tunnel config file should stop this.
No. Please read the comments documenting that configuration. It means that some attributes from the *inner-tunnel* reply aren't copied to the outer reply. It isn't deleting EAP-Message from the outer reply.
Especially given that it stops me seeing any of the other attributes (apart from User-Name but that was purposefully left in for account purposes).
No, it doesn't do that. You can still see the attributes. The inner reply attributes are still copied to the outer reply. EXCEPT for attributes which shouldn't be copied. Because we know that it doesn't make sense to copy them. You shouldn't be asking "why is the default configuration wrong". Instead, you should be describing what you're doing, what the server does, and why that's different from what you expect. Alan DeKok.
participants (3)
-
Alan DeKok -
FreeRAD -
Matthew Newton