Description of problem: Customer configured an httpd proxy server on the OCP HAProxy server to proxy the oauth/saml authentication through mod_auth_mellon. Users are able to authenticate to the IdP and redirected to OCP. However, is they try to configure a clientCA pem within the master-config.yaml the authentication as described above no longer succeeds. Proxy ssl.conf; SSLProxyEngine On SSLCertificateFile /etc/httpd/conf.d/aerocp.oshift1.lmtas.lmco.com.crt SSLCertificateKeyFile /etc/httpd/conf.d/aerocp.oshift1.lmtas.lmco.com.key SSLProxyMachineCertificateFile /etc/httpd/conf.d/aerocp.oshift1.lmtas.lmco.com.pem Certificate creation is fairly generic using a COTS PKI management tool called Venafi. Its a 2048/sha256/RSA cert using our internal CA then exported in PEM (OpenSSL) format w/Root Chain. CN and SAN of the host are the only parameters included.
Can you please provide information about the certificate in this file: /etc/httpd/conf.d/aerocp.oshift1.lmtas.lmco.com.pem Which is the SSLProxyMachineCertificateFile It needs to contain: 1. The client certificate with Key Usage of "TLS Web Client Authentication" 2. The private key of the cert. The only certificate I see in the case is clientCA+key.txt, that ceritificate is OK to server the proxy's clients as it has "X509v3 Extended Key Usage: TLS Web Server Authentication". however this certificate is NOT usable to authenticate the proxy to the the upstream server it want's to reach. So if this certificate was exported into /etc/httpd/conf.d/aerocp.oshift1.lmtas.lmco.com.pem then that's a mistake. A separate client certificate is need for that, or the certificate obtained must have both usages.
When generating the CSR for the client certificate pass in an openssl.cnf config file (with the -config option) with the following contents: --- [ clientauth ] basicConstraints=CA:FALSE extendedKeyUsage=critical,clientAuth --- if you want a cert with dual usage simply set extendedKeyUsage=critical,clientAuth,serverAuth The CA may decide to retain data passed in the CSR or change it. So once your CA sign the cert you have to verify that it did in fact grant both key usages in the cert it released back to you. HTH
Was the probelm solved by proper certificate generation and configuration ?
No status update form them so I just checked in with them for a status. Thanks.
It is not clear to me why the two certs are named PEM and CRT when they are probably both in the same PEM format. however if the names indicate that the .crt one is set in the SSLCertificateFile option, while the .pem one has been set in the SSLProxyMachineCertificateFile as for the previous configuration, then the problem is simply that the certs have been inverted. Just to reiterate: - SSLCertificateFile: is the proxy's *serving* certificate, i.e. the certificate presented to the proxy clients; it needs only an extended key usage of "TLS Web Server Authentication" to be recognized as a serving cert - SSLProxyMachineCertificateFile: is the proxy's client cert used to authenticate the proxy to the server it proxies to; it needs only an extended key usage of "TLS Web Client Authentication" to be recognized as a valid client cert. Note: the fact the client cert also has "TLS Web Server Authentication" key usage is generally not a problem. Also note that if you have a cert with both usage enabled then you can use that cert for both fields, however this is not recommended. HTH.
Customer found a mistake he made and once corrected, the new certificates allowed things to work as expected. Thanks for the help!
You are welcome.
Can this be reopened as a documentation bug to enhance the documentation to include how to set this up? The customer made the point that the steps taken to finally make this work are not documented anywhere that we know of.
Reopening as a DOCs bug. Enhance the documentation to include how to set this up? The customer made the point that the steps taken to finally make this work are not documented.
I sent Simo an email with some questions about this change.
Simo says that adding "Create the certificate for the Apache configuration. The certificate that you specify as the `SSLProxyMachineCertificateFile` parameter value is the proxy's client cert that is used to authenticate the proxy to the server. It must use `TLS Web Client Authentication` as the extended key type." to the "Configuring Apache" section of this topic should address the issue: https://docs.openshift.com/container-platform/3.9/install_config/configuring_authentication.html#RequestHeaderIdentityProvider
I created a PR here: https://github.com/openshift/openshift-docs/pull/10407 @Xiaoli, will you PTAL?
The step added is OK.
Thanks Chuan Yu! I have one more question for Simo before I merge.
Commits pushed to master at https://github.com/openshift/openshift-docs https://github.com/openshift/openshift-docs/commit/baec8fd0a40b754e174bb1e6aca2c3ec6066c9b3 bug 1564237 add cert description https://github.com/openshift/openshift-docs/commit/7df71576b5fabb8f36dea96e9c67a65ce5be7bf3 Merge pull request #10407 from kalexand-rh/BZ1564237 bug 1564237 add cert description
Simo +1'd the change. I've merged it and am waiting for it to go live.
This change is live on docs.openshift, eg: https://docs.openshift.com/container-platform/3.9/install_config/configuring_authentication.html#RequestHeaderIdentityProvider and on the portal, eg: https://access.redhat.com/documentation/en-us/openshift_container_platform/3.7/html-single/installation_and_configuration/#RequestHeaderIdentityProvider