如何在Ubuntu16.04上使用Let'sEncrypt保护GitLab
状态: 已弃用
本文介绍了一种使用 Let's Encrypt 手动配置 GitLab 的旧方法。 从 GitLab 版本 10.5 开始,Gitlab 原生提供 Let's Encrypt 支持。
我们关于 如何在 Ubuntu 16.04 上安装和配置 GitLab 的指南已更新,以包含 GitLab 中的相关配置设置。 我们建议您参考该指南继续前进。
介绍
GitLab,特别是 GitLab CE(社区版),是一个开源应用程序,主要用于托管 Git 存储库,具有其他与开发相关的功能,如问题跟踪。 GitLab 项目使得在您自己的硬件上设置一个 GitLab 实例变得相对简单,并且具有简单的安装机制。
默认情况下,GitLab 通过普通的、未加密的 HTTP 提供页面。 与任何处理登录凭据等敏感信息的 Web 应用程序一样,GitLab 应配置为通过 TLS/SSL 提供页面以加密传输中的数据。 这对于 GitLab 非常重要,因为您的项目的代码库可能会被能够拦截您的登录凭据的人更改。
Let's Encrypt 项目可用于轻松获取任何网站或 Web 应用程序的可信 SSL 证书。 Let's Encrypt 提供由其证书颁发机构签名的证书,所有现代 Web 浏览器都信任该证书颁发机构,前提是您可以证明您拥有您申请证书的域。
在本指南中,我们将演示如何配置安装在 Ubuntu 16.04 上的 GitLab 实例,以使用从 Let's Encrypt 获得的可信 SSL 证书。 这将保护与用户的所有传出通信,并确保密码、代码和任何其他通信受到保护,不会被外部各方读取或篡改。
先决条件
要完成本指南,您需要在 Ubuntu 16.04 服务器上安装 GitLab 实例。 我们假设您已按照我们的 如何在 Ubuntu 16.04 上安装和配置 GitLab 指南进行设置。
为了从 Let's Encrypt 获取证书,您的服务器必须配置有完全限定域名 (FQDN)。 如果您还没有注册域名,您可以在众多域名注册商之一注册一个(例如 Namecheap、GoDaddy 等)。
如果您还没有,请务必创建一个 A 记录,将您的域指向您服务器的公共 IP 地址。 这是必需的,因为 Let's Encrypt 如何验证您是否拥有它为其颁发证书的域。 例如,如果您想获得 gitlab.example.com
的证书,则该域必须解析到您的服务器,验证过程才能正常工作。 您需要一个具有指向您服务器的有效 DNS 记录的真实域才能成功完成本指南。
安装 Certbot,让我们加密客户端
在我们为 GitLab 安装获取 SSL 证书之前,我们需要下载并安装 Certbot,官方的 Let's Encrypt 客户端。
Certbot 开发人员使用最新版本的软件维护自己的 Ubuntu 软件存储库。 由于 Certbot 处于如此积极的开发中,因此值得使用此存储库来安装比 Ubuntu 提供的更新的 Certbot。
首先,添加存储库:
sudo add-apt-repository ppa:certbot/certbot
您需要按 ENTER
接受。 之后,更新包列表以获取新存储库的包信息:
sudo apt-get update
最后,使用 apt-get
安装 Certbot:
sudo apt-get install certbot
现在安装了 Certbot,我们可以准备我们的服务器,以便它可以成功响应 Let's Encrypt 在颁发证书之前要求的域所有权验证测试。
准备 Let's Encrypt Web 根域验证
为了从 Let's Encrypt 证书颁发机构接收 SSL 证书,我们必须证明我们拥有将提供证书的域。 有多种方法可以证明域所有权,每种方法都需要对服务器的 root 或管理员访问权限。
GitLab 包含一个内部管理的 Nginx Web 服务器,用于为应用程序本身提供服务。 这使得安装相当独立,但在尝试修改 Web 服务器本身时确实增加了额外的复杂性。
由于嵌入式 Nginx 目前被用于为 GitLab 本身提供服务,因此最好的域验证方法是 web 根方法。 Certbot 将使用现有的 Web 服务器在端口 80 上从服务器提供已知文件。 这向证书颁发机构证明,请求证书的人对 Web 服务器具有管理控制权,这有效地证明了对服务器和域的所有权。
要为 GitLab 设置 Web 根域验证,我们的第一步是创建一个虚拟文档根:
sudo mkdir -p /var/www/letsencrypt
这将不会被正常的 Nginx 操作使用,但会被 Certbot 用于域验证。
接下来,我们需要调整 GitLab 的 Nginx 配置以使用该目录。 通过键入以下命令打开主 GitLab 配置文件:
sudo nano /etc/gitlab/gitlab.rb
在里面,我们需要添加一行,将自定义指令注入 GitLab 的 Nginx 配置文件。 最好向下滚动到文件的 GitLab Nginx 部分,但该行可以放在任何地方。
粘贴到以下行:
/etc/gitlab/gitlab.rb
. . . nginx['custom_gitlab_server_config'] = "location ^~ /.well-known { root /var/www/letsencrypt; }" . . .
Let's Encrypt Web 根验证方法将文件放在文档根的 .well-known
目录中,以便证书颁发机构可以验证它。 这一行告诉 Nginx 为我们刚才创建的 web 根目录提供对 /.well-known
的请求。
完成后,保存并关闭文件。
接下来,通过再次重新配置应用程序将更改应用到 GitLab 的 Nginx 配置:
sudo gitlab-ctl reconfigure
现在应该设置服务器以成功验证您的域。
使用 Certbot 申请证书
现在 GitLab 的 Nginx 实例配置了必要的位置块,我们可以使用 Certbot 来验证我们的域名并请求证书。
因为我们只想要一个证书而不希望自动重新配置 Web 服务器,所以我们将使用 certonly
子命令。 我们将指定三个选项。 我们需要选择 web 根认证器(--webroot
),传入文档根目录(--webroot-path=/var/www/letsencrypt
),然后使用 -d
命令传递我们的域名:
sudo certbot certonly --webroot --webroot-path=/var/www/letsencrypt -d your_domain
您将被要求提供一个电子邮件地址。 包含有效的电子邮件地址很重要,因为这是可靠接收有关证书到期和其他重要信息的电子邮件的唯一方法。 您还将被提示接受 Let's Encrypt 服务条款。
完成后,如果 Let's Encrypt 能够正确验证所有权,它应该为您颁发该域的证书。 您应该会看到类似于以下内容的输出:
OutputIMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/gitlab.example.com/fullchain.pem. Your cert will expire on 2017-07-26. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you lose your account credentials, you can recover through e-mails sent to sammy@example.com. - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
您可以通过查看具有 sudo
权限的 /etc/letsencrypt/live/your_domain
目录来找到创建的所有证书和密钥:
sudo ls /etc/letsencrypt/live/your_domain
Outputcert.pem chain.pem fullchain.pem privkey.pem
对于我们的配置,我们只需要知道 fullchain.pem
和 privkey.pem
文件的完整路径。
配置 GitLab 以使用 Let's Encrypt 证书
现在我们已经从 Let's Encrypt 获得了可信证书,我们可以将 GitLab 配置为对其所有流量使用 TLS/SSL。
编辑 GitLab 配置
首先再次打开 GitLab 配置文件:
sudo nano /etc/gitlab/gitlab.rb
在顶部,更改 external_url
。 目前,它可能指向 http://your_domain
。 我们只需要将 http
更改为 https
:
/etc/gitlab/gitlab.rb
. . . external_url 'https://your_domain' . . .
接下来,向下滚动到 GitLab Nginx 部分。 取消注释并修改,或简单地添加以下行。
重定向行告诉 Nginx 自动将向 HTTP 端口 80 发出的请求重定向到 HTTPS 端口 443。 ssl_certificate
行应指向 fullchain.pem
文件的完整路径,而 ssl_certificate_key
行应指向 privkey.pem
文件的完整路径:
/etc/gitlab/gitlab.rb
. . . nginx['redirect_http_to_https'] = true . . . nginx['ssl_certificate'] = "/etc/letsencrypt/live/your_domain/fullchain.pem" nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/your_domain/privkey.pem" . . .
完成后保存并关闭文件。
允许 HTTPS 流量通过防火墙
接下来,在重新加载 GitLab 的 Nginx 配置之前,请确保允许 HTTPS 流量通过服务器的防火墙。 为此,您可以通过键入以下命令打开端口 443:
sudo ufw allow https
OutputRule added Rule added (v6)
通过键入以下命令检查端口 443 是否打开:
sudo ufw status
OutputStatus: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 80 ALLOW Anywhere 443 ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) 80 (v6) ALLOW Anywhere (v6) 443 (v6) ALLOW Anywhere (v6)
如您所见,端口 443 现在已公开。
重新配置 GitLab 以启用 SSL
现在,再次重新配置 GitLab 以实现您的更改:
sudo gitlab-ctl reconfigure
现在应该可以使用您信任的 Let's Encrypt 证书通过 HTTPS 访问您的 GitLab 实例。 您可以通过访问 GitLab 服务器的域名来测试这一点。 由于我们将 HTTP 重定向到 HTTPS,这应该可以在没有明确指定协议的情况下工作:
http://your_domain
您的浏览器应该会自动将您重定向到使用 HTTPS。 您应该会在地址栏中看到一些指示该站点是安全的:
您的 GitLab 安装现在受到 TLS/SSL 证书的保护。
验证 Certbot 自动续订
Let's Encrypt 的证书有效期只有九十天。 这是为了鼓励用户自动化他们的证书更新过程。 我们安装的 certbot
软件包通过 systemd 计时器每天运行两次“certbot renew”来为我们解决这个问题。 在非系统发行版上,此功能由放置在 /etc/cron.d
中的脚本提供。 此任务每天运行两次,并将续订到期后三十天内的任何证书。
要测试更新过程,您可以使用 certbot
进行试运行:
sudo certbot renew --dry-run
如果您没有看到任何错误,则说明一切就绪。 必要时,Certbot 将更新您的证书并重新加载 Nginx 以获取更改。 如果自动续订过程失败,Let's Encrypt 将向您指定的电子邮件发送一条消息,在您的证书即将到期时警告您。
结论
您的 GitLab 实例现在应该受到所有现代浏览器都信任的安全 TLS/SSL 证书的保护。 虽然配置嵌入式 Nginx 实例比设置独立的 Nginx Web 服务器要复杂一些,但由于 GitLab 在其配置文件中公开了自定义位置块的功能,因此很容易解决。
现在您的 GitLab 实例是安全的,它可以安全地用于管理项目、托管代码存储库和配置持续集成。 您可以在我们关于 使用 GitLab CI 设置持续集成管道的文章中了解如何使用 GitLab 自动测试对存储库的每个提交。