Trusting self-signed certificates

[jboalml]

I am trying to connect to a resource server using Oathkeeper in Docker for Windows and, since I am still in my development setup, I am using self-signed certificates. So far, I have successfully managed to hit the resource server, but Oathkeeper keeps complaining about the server certificate being signed by an unknown authority. The log message is the following:

time="2019-04-18T15:43:38Z" level=warning msg="Access request denied because roundtrip failed" error="x509: certificate signed by unknown authority" granted=false
2019/04/18 15:43:38 http: proxy error: x509: certificate signed by unknown authority

It would be useful to support using self-signed certificates in Oathkeeper to allow testing HTTPS connections before going into production. I suggest two options:

• Incorporate a flag to disable resource server certificate verification, just like --skip-tls-verify in Hydra. However, this should not affect incoming TLS connections.
• Being able to feed the certificate chain to perform validation.

I believe both alternatives have different use cases. The first one would allow to quickly test HTTPS communication with resource servers, whereas the second would be useful to secure last mile connections in those scenarios where you cannot or do not want to use certificates signed by a CA.

Any help would be greatly appreciated.

P.S. This an extended repost of the following forum message suggested by @arekkas.

[aeneasr]

Just to get it right - you want the connectivity to the upstream server to be encrypted in transport (HTTP over TLS) with self-signed certificate which fails because of CA verification?

[jboalml]

Just to get it right - you want the connectivity to the upstream server to be encrypted in transport (HTTP over TLS) with self-signed certificate which fails because of CA verification?

Yes, this is exactly the problem. My development resource server does not have a public domain name and therefore I cannot use a certificate signed by a CA. The only solution I have found so far is to secure Oathkeeper's incoming requests and change my upstream redirection to HTTP.

[aeneasr]

Sorry for the late reply, sounds like a reasonable feature request. Open to accept PRs!

[wraix]

I have created a function that should do what is required, but im having trouble figuring out how to implement the configuration part. Help would be appreciated. - At least this shows how to implement extending the Root CA for upstream connections.

This is not ready to be merged. I just did not understand how pull requests work on forks. Is my first time, sorry.

[candidoma]

Any news about this?

[wraix]

Yes i have completed the code that does the heavy lifting, hope it will be satisfactory.

Update: I have added documentation and checked the code for formatting so that should be in order.

I am a little in doubt about the test case. It will require mocking an upstream server which seem like a lot of work as there is no pre-existing test for upstream connectivity, i might just leave it here...

[wraix]

The feature should be completed in PR 706

[ReeganExE]

Hi team, how about authenticators? Does oathkeeper currently support TLS with self-signed cert? I believe TLS is being used everywhere even internal communication nowadays.

authenticators:
  cookie_session:
    enabled: true
    config:
      check_session_url: https://kratos:4433/sessions/whoami
      preserve_path: true
      extra_from: "@this"
      subject_from: "identity.id"

[aeneasr]

Not yet, I think support for custom CAs should be something for Oathkeeper next (#441)! I think the easiest workaround for now is to register the certificate in the trust store of the OS / container?

[github-actions]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan on resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneous you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️