locked
Client Certificate Authentication RSA certificate ignored when ECC installed RRS feed

  • Question

  • Hi,

    Having some fun with a windows 7 setup of DirectAccess, have it configured to use ECC certificates on the client for the IPSec authentication, which was working brilliantly, we even have it loaded up behind a Citrix Netscaler to do SSL offloading of the HTTPS tunnel encryption. But when trying to get Client Preauthentication working, we hit a snag, it seems that the NetScalers dont support ECC certificates, which is a pain, but something we thought we could work around by using an RSA certificate on the client to performed the pre-authentication (as shown here https://directaccess.richardhicks.com/2016/05/10/directaccess-ip-https-preauthentication-using-citrix-netscaler/).

    So we have three CA's, CA1/2 issue RSA certs and CA3 is setup to do the ECC ones, so nice separation of the chains.

    So we have our Cert chain for RSA loaded into the load balancer and a new cert issued to the client from CA1... But, every time the client connects to the server (LB) we see the handshake taking place, the server sends a list of its DNs (CA1/2) (https://blogs.msdn.microsoft.com/kaushal/2015/05/27/client-certificate-authentication/) to the client, but then the client looks in its store, picks out the ECC certificate (issued from CA3) and fails to authenticate saying no suitable certificate can be found, its like its not even looking at the RSA one at all.

    So, thinking something was wrong with the way the LB was asking for client authentication, I tried deleting the ECC cert and tried again... this time, the client completes the handshake, finds the RSA cert and passes it back to the LB for authentication. So, im left wondering why my Windows 7 client is trying to use a Cert issued by a CA which isnt in the list of DN's sent by the LB. 

    To add insult to this issue, trying this same scenario on Windows 10 seems to work out of the box, with an ECC cert and RSA cert in the Computer personal store the client looks and chooses the RSA one, authenticates and continues through the process of connecting.

    Tuesday, July 12, 2016 8:42 PM

Answers

  • Seems we may have resolved this one today. We had two certificates on the box, one RSA from SCCM with no Subject set in its configuration, and the ECC DirectAccess one with Subject name set to the machines Common Name. Both certs were set to with the capability of Client Authentication.

    It seems that Windows 7 will always choose the cert with the Subject name set over the other one, we re-issued a new RSA certificate with the Subject Name set to CN, and after reconnecting the client we can see windows receives the query from the Load Balancer for authentication, then the client chooses the newly issued RSA cert (not the ECC one as before).

    We now have some work to do in terms of getting SCCM to carry on authenticating, as having both RSA certs on the box will undoubtedly confuse SCCM, as it will now try and use the newly issued RSA one instead of its own (further testing required)...

    • Marked as answer by FluxboxUK Wednesday, July 13, 2016 5:58 PM
    Wednesday, July 13, 2016 5:58 PM

All replies

  • Hi FluxboxUK,

    The main issue is that the client didn`t select the certificate included in the list of the server DNs, right?

    First of all, please ensure all the machines are up to date.

    As the link you have posted pointed out, "This can lead to a problem where few systems require Root CA‘s while few require Intermediate CA‘s to be present in the list sent in the SERVER HELLO. This makes the communicating parties incompatible on certain occasions.

    Both the implementations are debatable. On one hand the list sent by the server cannot exceed a certain limit (on windows the size is 12,228 bytes). If exceeded, the auth will fail. The list of Intermediate CA’s always exceeds the list of Root CA by 2-3 folds or even higher. This is one of the reasons why some systems send the ROOT CA’s in the list of Distinguished CA Names. On the other hand, the Intermediate CA names are readily available in the client certificate provided by the user, so it makes it easier during the certificate chain validation, therefore some systems prefer this over the previous one. Both have their own merits"

    We could try the workaround included in the following link. Add a registry key, "SendTrustedIssuerList". Deleting some root certificate is a solution, too.

    https://support.microsoft.com/en-us/kb/933430/

    Best regards


    Please mark the reply as an answer if you find it is helpful.

    If you have feedback for TechNet Support, contact tnmff@microsoft.com






    Wednesday, July 13, 2016 3:07 AM
  • Seems we may have resolved this one today. We had two certificates on the box, one RSA from SCCM with no Subject set in its configuration, and the ECC DirectAccess one with Subject name set to the machines Common Name. Both certs were set to with the capability of Client Authentication.

    It seems that Windows 7 will always choose the cert with the Subject name set over the other one, we re-issued a new RSA certificate with the Subject Name set to CN, and after reconnecting the client we can see windows receives the query from the Load Balancer for authentication, then the client chooses the newly issued RSA cert (not the ECC one as before).

    We now have some work to do in terms of getting SCCM to carry on authenticating, as having both RSA certs on the box will undoubtedly confuse SCCM, as it will now try and use the newly issued RSA one instead of its own (further testing required)...

    • Marked as answer by FluxboxUK Wednesday, July 13, 2016 5:58 PM
    Wednesday, July 13, 2016 5:58 PM