Dex and ssl certs

Which part of the code updates ssl certs in /etc/ood/dex?
If you are using an ssl cert with chain cert you need to cat CAChain into your cert. Otherwise curl and other ssl checkers fail due to missing chain cert. What do you guys suggest doing? Just concatenate prior myCAChain.crt >> my .crt and drop apache SSLCertificateChainFile line?

  • ‘SSLCertificateFile “/etc/pki/tls/certs/my.crt”’
  • ‘SSLCertificateKeyFile “/etc/pki/tls/private/my.key”’
  • ‘SSLCertificateChainFile “/etc/pki/tls/certs/myCAChain.crt”’

Think I’ll just cat CAChain.crt >> site.crt to keep it simple and not require any code changes or work arounds.

Hi Jesse, sorry for the delay in response.

The /etc/ood/dex config is handled by the ood-portal-generator app. The pieces of the app which specifically handle dex are in:
ood-portal-generator/lib/ood_portal_generator/dex.rb
Which uses entries from:
/etc/ood/config/ood_portal.yml

If you scroll to the bottom of that yaml file, you can see the dex: key which then has further attributes below you can set that will then be pulled into that dex.rb file for use in constructing the config for dex.

For Apache SSL directives the relevant settings are found further up in that ood_portal.yml where you can see the following:

List of SSL Apache directives
Example:
ssl:
- ‘SSLCertificateFile “/etc/pki/tls/certs/www.example.com.crt”’
- ‘SSLCertificateKeyFile “/etc/pki/tls/private/www.example.com.key”’
Default: null (no SSL support)
ssl: null

As for the CAChain, catting that into your crt seems like the most straightforward way to handle the chain dependency assuming the proper order is maintained. However, this makes me realize there is nothing to handle the CAChain.crt at the moment, so that’s a good catch that we will have to address. I will be opening an issue to address this. Thanks for the question and please let us know if you need anything else.

Yeah this just bit me, unless I cat’d the fullchain of a letsencrypt cert into the cert file itself I was left with dex erroring on the generic:

http: TLS handshake error from <ip address>:58758: local error: tls: bad record MAC

Is this an upstream Dex issue?

Wonder if this has to do with letsencrypt certs being their own CA now, but Dex should use the system CA store right?

I do not see this being a dex issue, what it expects from CA certificates. You can add CA to your trusted-ca. For RHEL direviatives drop CAcert in /etc/pki/ca-trust/source/anchors/ and run update-ca-trust

HTH,
Jesse