Hi Conan, I am sorry that it's not working for you. I believe there must be some different setup there in your environment than how I tested, that's why it's working for me but not for you. However as it will require some additional time and more engagement with you ( to understand your environment ), I think it's better for you to move forward with [VIP support](https://www.gluu.org/gluu-server/pricing/) where we will have opportunities to work more intensely with you. I am sorry that I couldn't help you more on this issue from community support room.

Hi Mohib. I work with Conan and appreciate the time you have spent answering our questions, so thank you. Our organization is in the process of identifying a identity management solution and as my department has been trying to implement an identity solution (Gluu) for a while now I have been volunteered into the project that will deliver this. I don't know what the outcome will be so I don't think we could purchase support currently. I will ask. I understand your situation but wondered if you could answer a few more questions about certificates (sorry), So... when you tested certificates with Nginx can you tell me did you run the Nginx server on a different host from the Gluu server? We can get client certs working with just Gluu but as soon as we proxy through Nginx either on same host that is running Gluu or on a separate server we just can't get certificates to work and keep getting the error that Conan has described. If we include the client chain-cert directly in our Nginx configuration and dump the headers we see the following that looks promising. ssl_client_certificate /etc/ssl/certs/chain-cert.pem; ssl_verify_client optional; ssl_verify_depth 2; proxy_set_header X-ClientCert-DN $ssl_client_s_dn; proxy_set_header X-ClientCert $ssl_client_cert; HTTP Headers dump. HTTP_HOST = auth.ourdomain.org HTTP_X_REAL_IP = 192.168.xx.yy HTTP_X_FORWARDED_FOR = 192.168.xx.yy HTTP_X_CLIENTCERT_DN = /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=conan gluu cert HTTP_X_CLIENTCERT = -----BEGIN CERTIFICATE----- MII...ALL_THE_CERT_TEXT......= -----END CERTIFICATE----- It seems to me that we either need to pass the certificate from Nginx to apache in a header or if it's possible just pass the ClientCert-DN. There appears to be issues with passing the cert in the header, using the $ssl_client_cert variable results in tabs being included in the certificate so I don't think that would work and passing the raw cert doesn't work easily without adding additional modules (we might try that later). So I was wondering if it's possible to pass the "X_CLIENTCERT_DN" header to apache and them somehow pass that into jetty/gluu and force it so that the user/cert has been trusted already ? Again sorry for all the questions, We must be close to getting this to work. Thanks Keith

Hi Keith, Nice to meet you ( virtually )! :-) >> when you tested certificates with Nginx can you tell me did you run the Nginx server on a different host from the Gluu server? Yes, Nginx was in different VM. >> We can get client certs working with just Gluu but as soon as we proxy through Nginx either on same host that is running Gluu or on a separate server we just can't get certificates to work and keep getting the error that Conan has described. Ok, that's a good point. So... cert-authN configuration is ok. >> ssl_certificate /etc/nginx/ssl/cert.crt; >> ssl_certificate_key /etc/nginx/ssl/private.key; Just to give you a note... this configuration inside nginx... this 'cert.crt' and 'private.key' are certificate /private key from Gluu Server; that means... Gluu Server's HTTPD key and Cert.