Bug 1564237 - [DOCS] [RFE] RequestHeaderIdentityProvider Fails When clientCA Certificate Configured
Summary: [DOCS] [RFE] RequestHeaderIdentityProvider Fails When clientCA Certificate Co...
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Documentation
Version: 3.7.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
: ---
Assignee: Kathryn Alexander
QA Contact: Chuan Yu
Vikram Goyal
Depends On:
TreeView+ depends on / blocked
Reported: 2018-04-05 18:52 UTC by Jack Ottofaro
Modified: 2021-06-10 15:41 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-06-29 18:21:32 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Jack Ottofaro 2018-04-05 18:52:39 UTC
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.

Comment 1 Simo Sorce 2018-04-05 19:30:39 UTC
Can you please provide information about the certificate in this file:

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.

Comment 3 Simo Sorce 2018-04-06 00:12:00 UTC
When generating the CSR for the client certificate pass in an openssl.cnf config file (with the -config option) with the following contents:
[ 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.


Comment 4 Simo Sorce 2018-04-11 13:37:28 UTC
Was the probelm solved by proper certificate generation and configuration ?

Comment 5 Jack Ottofaro 2018-04-11 13:58:34 UTC
No status update form them so I just checked in with them for a status. Thanks.

Comment 7 Simo Sorce 2018-04-17 13:03:35 UTC
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.


Comment 8 Jack Ottofaro 2018-04-17 13:14:16 UTC
Customer found a mistake he made and once corrected, the new certificates allowed things to work as expected. Thanks for the help!

Comment 9 Simo Sorce 2018-04-17 21:15:14 UTC
You are welcome.

Comment 10 Jack Ottofaro 2018-04-18 13:35:28 UTC
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.

Comment 11 Jack Ottofaro 2018-04-19 19:44:42 UTC
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.

Comment 12 Kathryn Alexander 2018-06-22 18:20:02 UTC
I sent Simo an email with some questions about this change.

Comment 13 Kathryn Alexander 2018-06-25 13:04:06 UTC
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

Comment 14 Kathryn Alexander 2018-06-25 19:24:42 UTC
I created a PR here: https://github.com/openshift/openshift-docs/pull/10407

@Xiaoli, will you PTAL?

Comment 15 Chuan Yu 2018-06-29 08:57:39 UTC
The step added is OK.

Comment 16 Kathryn Alexander 2018-06-29 12:57:37 UTC
Thanks Chuan Yu! I have one more question for Simo before I merge.

Comment 18 Kathryn Alexander 2018-06-29 14:28:12 UTC
Simo +1'd the change. I've merged it and am waiting for it to go live.

Note You need to log in before you can comment on or make changes to this bug.