Tls_client_auth - any tips on working out why it is failing

Troubleshooting
, ,
#1

I have configured tls_client_auth as per the instructions for FRAM 7.2.0, but it fails with

{
    "error_description": "Client authentication failed",
    "error": "invalid_client"
}

when I send

curl --location --request POST 'https://fram.connectid.darkedges.com/openam/oauth2/access_token' \
--header 'X-SSL-CERT: -----BEGIN%20CERTIFICATE-----%0AMIIEnjCCA4agAwIBAgIUTBokdwRUwdhoDg9ybfm9NU5%2Fjo4wDQYJKoZIhvcNAQEL%0ABQAwSTESMBAGA1UEChMJRm9yZ2VSb2NrMQ0wCwYDVQQLEwRJREFNMSQwIgYDVQQD%0AExtGb3JnZVJvY2sgSURBTSBJbnRlcm1lZGlhdGUwHhcNMjIxMDE0MjIzMTE4WhcN%0AMjMxMDE0MjIzMTQ4WjBjMQswCQYDVQQGEwJBVTERMA8GA1UECBMIVmljdG9yaWEx%0AEjAQBgNVBAcTCU1lbGJvdXJuZTEtMCsGA1UEAxMkNTkyMTUzOGItOWM1Mi00ODkw%0ALWI0YzAtMmFmNmJiZDE3ODllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC%0AAQEA1aJ%2FhTSow8O69RS%2FHoM0gnzvSpKXTtyZUr52Zx5%2F%2BPrKDq%2BR99cOAe4biZWI%0ApQwW5PXpX0PvcyI1qlNEp6szBZ5RBjlGFvqB5IdbLUiejcWvohbwYBm7NbvmqNuv%0AT47JIw81yzr38oue2ZFLv10M5Xehbcf4RPekdSfAN6OEhJ%2BaE7%2FcXoFGbs8jO0Mr%0AQMdOBUB5KfcNczISkZzVeAzCPgXGw3CHj9qXSA2vpU%2Fow1cBArCj2ayhjh2P%2F1Wq%0AniG3%2FSNLu%2B6BhSHmfmEZunWbYwo4cag0nINq1sScvRB%2BYK45v3d9%2Be4BHK44Bfe%2B%0AQGc7zlbjlvZeyO469l1Oe1VJDwIDAQABo4IBYjCCAV4wDgYDVR0PAQH%2FBAQDAgOo%0AMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUVRMEK0ii%0AAXfEjcdX%2Fa3U3T3YzXcwHwYDVR0jBBgwFoAUSkAaDYPBgQ8AXA5tBokaAvFJrkEw%0AYgYIKwYBBQUHAQEEVjBUMFIGCCsGAQUFBzAChkZodHRwczovL3ZhdWx0LmludGVy%0AbmFsLmRhcmtlZGdlcy5jb20vdjEvZm9yZ2Vyb2NrX2lkYW1faW50ZXJtZWRpYXRl%0AL2NhMC8GA1UdEQQoMCaCJDU5MjE1MzhiLTljNTItNDg5MC1iNGMwLTJhZjZiYmQx%0ANzg5ZTBYBgNVHR8EUTBPME2gS6BJhkdodHRwczovL3ZhdWx0LmludGVybmFsLmRh%0AcmtlZGdlcy5jb20vdjEvZm9yZ2Vyb2NrX2lkYW1faW50ZXJtZWRpYXRlL2NybDAN%0ABgkqhkiG9w0BAQsFAAOCAQEAKYCodncCin3hFDh%2BHWutE79aN4bRmy4hloGe6iw1%0AtnGFYeELnHnyrwqahB4LRdiE%2Fet0%2Fwvp9ML7chKkj3KBDrwkIeZLiBSHcAYPRdKs%0ACIm1QrXfcmDUpePdZuhw5Jvj9K0n6zDj01l7o7oxcN0iM4CfY9hBnRPQW4%2BsX%2BdQ%0A%2BK4jXJmUKhv1FB35frNlZFPQErsv9hvgheKjlBx0Uod8YWZQIbK%2FNiuT7nwKYffG%0A7IiwvYkIHCk8UHIROAQZbyWdNCemIqEHgD0rjGjrziBs5Haeq9T7iKUCmsy8aPbY%0AzWXx22Q1O8HepjJ4u23XyRj6eE8HmKY8naVbiqTJcyygVw%3D%3D%0A-----END%20CERTIFICATE-----' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=5921538b-9c52-4890-b4c0-2af6bbd1789e' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=profile' \
--data-urlencode 'response_type=token'

I believe it is finding the correct secret mapping as I have enabled otherlogging debug logging and can see it find the secret correctly. I have entered the SubjectDN as CN=5921538b-9c52-4890-b4c0-2af6bbd1789e,L=Melbourne,S=Victoria,C=AU but there is nothing in the logs that would indicate any issues. I can see it finds the trusted header as that shows up as found in the logs,

Any ideas on how to trouble shoot this?

Edit:
Found this when OAuth2Provider logging is enabled and set to Debug

OAuth mTLS authentication: set of trust anchors for client 5921538b-9c52-4890-b4c0-2af6bbd1789e is empty

Nicholas

1 Like
#2

Found a mistake on my behalf.

I was using am.services.oauth2.mtls.client.authentication instead of am.services.oauth2.tls.client.cert.authentication

It was one of those could not see the woods for the trees moment.

1 Like
#3

Welcome to the community @ nirving!

Thank you so much for providing a detailed narrative in your problem description and findings. We appreciate you sharing your valuable time and solution with the community!