unsupported certificate error with device certificates

[RobM]

Hello All.  I'd appreciate some help debugging an issue with new device certificates, and communication between two of our f5s.

We replaced the certs under Device Certificate Management, and each server has the full chain for both servers under Device Trust Certificates.  The message we see in the logs is:

Mar 16 10:34:53 s0711125-mgmt iqmgmt_ssl_connect: SSL error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 alert unsupported certificate

(Note that this is the full line.  In searching for similar cases on here I found a lot of cases where the log entry was "unsupported certificate purpose", but that is not the case here.  I tried turning the SSL logging up to debug, and got no additional information that I can see.)

In a packet trace I can see that the response is indeed a TLSv1.2 Alert: Unsupported Certificate response:

2447 0.284021 me partner TLSv1.2 84 OUT s1/tmm3 : Alert (Level: Fatal, Description: Unsupported Certificate)

The (redacted) cert that my partner presented looked like:

Certificate: 
    signedCertificate
        version: v3 (2)
        serialNumber: 
        signature (sha256WithRSAEncryption)
            Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)
        issuer: rdnSequence (0)
        validity
        subject: rdnSequence (0)
        subjectPublicKeyInfo
        extensions: 9 items
            Extension (id-ce-subjectAltName)
            Extension (id-ce-subjectKeyIdentifier)
            Extension (id-ce-authorityKeyIdentifier)
            Extension (id-ce-cRLDistributionPoints)
            Extension (id-pe-authorityInfoAccess)
            Extension (id-ce-keyUsage)
                Extension Id: 2.5.29.15 (id-ce-keyUsage)
                Padding: 5
                KeyUsage: a0
                    1... .... = digitalSignature: True
                    .0.. .... = contentCommitment: False
                    ..1. .... = keyEncipherment: True
                    ...0 .... = dataEncipherment: False
                    .... 0... = keyAgreement: False
                    .... .0.. = keyCertSign: False
                    .... ..0. = cRLSign: False
                    .... ...0 = encipherOnly: False
                    0... .... = decipherOnly: False
            Extension (id-ms-certificate-template)
                Extension Id: 1.3.6.1.4.1.311.21.7 (id-ms-certificate-template)
                CertificateTemplate
                    templateID: 1.3.6.1.4.1.311.21.8.14764644.7141585.13978757.4163610.14474613.168.14047150.174214 (iso.3.6.1.4.1.311.21.8.14764644.7141585.13978757.4163610.14474613.168.14047150.174214)
                    templateMajorVersion: 100
                    templateMinorVersion: 14
            Extension (id-ce-extKeyUsage)
                Extension Id: 2.5.29.37 (id-ce-extKeyUsage)
                KeyPurposeIDs: 1 item
                    KeyPurposeId: 1.3.6.1.5.5.7.3.1 (id-kp-serverAuth)
            Extension (id-ms-application-certificate-policies)
                Extension Id: 1.3.6.1.4.1.311.21.10 (id-ms-application-certificate-policies)
                CertificatePoliciesSyntax: 1 item
                    PolicyInformation
                        policyIdentifier: 1.3.6.1.5.5.7.3.1 (id-kp-serverAuth)
    algorithmIdentifier (sha256WithRSAEncryption)
    Padding: 0

Any thoughts on what might be causing this error?

Thanks much for any help,

     - rob.

[RobM · Accepted solution]

I believe that I may have worked this out, though I need a new cert, so I havent yet tested the solution.  The device cert that we received from our CA has the extended attribute:

            Extension (id-ce-extKeyUsage)
                Extension Id: 2.5.29.37 (id-ce-extKeyUsage)
                KeyPurposeIDs: 1 item
                    KeyPurposeId: 1.3.6.1.5.5.7.3.1 (id-kp-serverAuth)

But this document: Overview of BIG-IP device certificates (11.x - 16.x) (f5.com) states:

"SSL certificates signed by a third-party CA must include both the client authentication (clientAuth) and server authentication (serverAuth) extended key usage (EKU) extensions to allow use by both server and client applications."

Which makes sense.  I checked the request generated by our device, and it doesn't specify any restriction - might be worth it specifically requesting both clientAuth and serverAuth - so apparently adding the restriction was our CAs idea.