Skip to content

Add default ca_path to gitlab-shell for trusted certs

Catalin Irimie requested to merge cat-add-trustedcerts-default-gitlabshell into master

What does this MR do?

By default, the HTTP client inside gitlab-shell did not receive any custom certificate paths, so it uses the default system location.

Adding ca_path to the default makes it also load the trusted-certs symlinked certs in its pool of trusted certs.

Related issues

Closes #5727 (closed)

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion

Required

  • Merge Request Title, and Description are up to date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline on GitLab.com
  • Pipeline is green on dev.gitlab.org if the change is touching anything besides documentation or internal cookbooks
  • trigger-package has a green pipeline running against latest commit

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes

    Described in the first steps in #5727 (closed), essentially the gitlab-shell check should return OK after:

    export DOMAIN="REDACTED"
openssl req -x509 -newkey rsa:4096 -keyout /etc/gitlab/ssl/$DOMAIN.key -out /etc/gitlab/ssl/$DOMAIN.crt -days 365 -subj "/CN=$DOMAIN" -nodes
echo "letsencrypt['enable'] = false" >> /etc/gitlab/gitlab.rb
echo "gitlab_rails['internal_api_url'] = 'https://$DOMAIN'" >> /etc/gitlab/gitlab.rb
gitlab-ctl reconfigure
# wait for the Rails app to start again
/opt/gitlab/embedded/service/gitlab-shell/bin/check

  • Documentation created/updated

  • Tests added

  • Integration tests added to GitLab QA

  • Equivalent MR/issue for the GitLab Chart opened

    The gitlab-shell chart communicates to workhorse through HTTP, so this doesn't seem needed there.

Edited by Catalin Irimie

Merge request reports