-
Notifications
You must be signed in to change notification settings - Fork 80
Need test for mandatory client cert auth from router for reencrypt case #504
Comments
@richm Thanks for your feedback.
And after I create reencrypt route with the image above. The haproxy.config shows as the same what you have pasted.
And when I try to access the backend via the route, I got failed.
When I test the image on local, it works.
Looks like the I am not sure if this is the bug you mentioned in the router code. Here is the definition of the reencrypt route. If I got your point correctly, I think I can file bug or contact the devel for help. |
What is the sticky-reen.example.com server cert subject DN? subjectAltName?
I think it was really my misunderstanding of how to make the re-encrypt route work when the server requires client cert. I could not figure out how to configure the route to use client cert auth when re-encrypting the connection from the router to the server. That should be an RFE for OpenShift and/or Kubernetes. |
Here is the server cert info:
|
I think there is a problem with the cert.
It looks as though this is in the wrong order. For one, the order is different than the Issuer, which has CN as the righmost component. For another, here is what a working server cert looks like:
It is the CN value that the client side uses to check the server cert for MITM. This CN value should be the rightmost value in the Subject in order for the client to be able to use it for checking. |
@richm how do you obtain info about your cert? It seems that openssl text output does not necessarily match actual order. It can change using different options. For example:
I Believe @jianlinliu has generated the certificates by OpenSSL and I doubt format is invalid. What I would suspect is that the route is not using the desired certificate for some reason in the example above. One can see actual certificate returned by server in two easy ways:
btw you can see the google cert also appears with CN in the beginning but I believe this is only output formatting. One has to look lower level at cert to check actual order. Also full server chain can be extracted via
I think first thing is to check whether the route is returning the expected certificate to client. And only then check whether client cert validation is performed. |
I used |
For the router reencrypt test, client certs/keys are allowed, but do not appear to be used.
https://github.com/openshift-qe/v3-testfiles/blob/master/routing/reencrypt/route_reencrypt-path.json#L14
This sets up the route with cert and key. However, the /etc/Caddyfile in the caddy-docker pod looks like this:
The Caddy documentation shows this:
I believe
clients
should be configured like this to require client certs:or wherever the example_ca cert is stored.
I think the lack of testing is masking a bug in the router code in openshift, which may have been fixed in 1.4. In 1.3 /var/lib/haproxy/conf/haproxy.config looks like this:
Note the
server
line. I'm not sure which haproxy documentation is applicable to the haproxy version in OSE 3.3. But I did find this: https://www.haproxy.com/doc/aloha/7.0/haproxy/tls.html#configuring-haproxy-for-ssl-tlsI do not see a "crt" directive in the "server" line above. So I don't know how openshift is supposed to use the cert and key specified in the reencrypt route configuration.
The text was updated successfully, but these errors were encountered: