0

I am testing the WLAN functionalities of a device connecting to a RADIUS server. This RADIUS server is located on a Raspberry Pi with Raspbian Stretch and is using FreeRADIUS 3.0 and Hostapd.

Some of the EAP-TLS test cases check what happens if long "chains of trust" are used. By long chains of trust I mean public keys that have been signed by a long chain of intermediate certificates.

Now, I'm facing the problem that in some of the test cases FreeRADIUS returns a specific error in its log:

SSL says error 25 : path length constraint exceeded

One of these test cases is described below:

RADIUS certificate files:

  • Certificate: ServerCert - IM1 - RootCA (public key signed by IM1 signed by RootCA)
  • Private key: ServerKey
  • CA-certificate: IM3 - IM2 - IM1 - RootCA chain (chain formed of IM3, IM2, IM1 and RootCA)

Client certificate files:

  • Certificate: ClientCert - IM3 - IM2 - IM1 - RootCA (ClientCert signed by IM3 signed by IM2 signed by IM1 signed by RootCA
  • Private Key: ClientKey
  • CA-certificate: IM1 - RootCA chain (chain formed of IM1 and RootCA)

When trying to connect with this setup, after the client sent its Hello, the RADIUS server starts to send its CA-certificate chain instead of the expected server certificate (Saw this using Wireshark). Also it throws the error 25.

And now the questions:

  1. What does the error "SSL says error 25 : path length constraint exceeded" mean and does this have to do with the length of the chains of trust?

  2. Is the described configuration even legitimate?

  3. Why does the server send its CA-certificate chain and not the server certificate?

  4. Is there a limit for the number of intermediates used in a chain of trust?

1

What does the error "SSL says error 25 : path length constraint exceeded" mean and does this have to do with the length of the chains of trust?

This refers to the pathLenConstraint extension of the certificate. With this extension a CA can restrict the depth of the possible trust path. For example a CA might issue a sub-CA but restrict it so that this one cannot issue more additional sub-CA but only leaf certificates. See also Certificates Basic Constraint's Path Length.

Is the described configuration even legitimate?

Maybe or maybe not, depending if the path len is restricted to disallow a trust path of this length or not.

Why does the server send its CA-certificate chain and not the server certificate?

The server should send its leaf certificate and also the intermediate certificates which are needed to build the trust path to the trusted root CA. If the server only sends the chain but not the leaf certificate something is wrong. But maybe you did not notice that the server sends also the leaf certificate (should be the first) and not only the chain certificates.

Is there a limit for the number of intermediates used in a chain of trust?

If there is one given with pathLenConstraint then there is such a limit. If no such constraint is given there is no limit in theory but in practice TLS stacks might disallow insanely large chains.

  • Thank you very much. I created new certificates with a not set path length constraint for the intermediate certificates (Only for testing purposes). Before, the path length constraint was set to 0 in the Openssl configs, so the IM certs were not allowed to sign other IM certs. – Jannis Kappertz Sep 25 '17 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.