为网站启用https,使用容器化的 Let's Encrypt

背景

去年有记录过一篇 Let’s Encrypt ,不过是基于源码的。最近在为服务器做迁移,将运维组件也容器化。这篇文章记录我使用 容器化 Let’s Encrypt 的过程。更详细的操作步骤可以参考我以前的文章——《Let’s Encrypt》

什么是 Let’s Encrypt

Let’s Encrypt是国外一个公共的免费SSL项目,由 Linux 基金会托管,它的来头不小,由Mozilla、思科、Akamai、IdenTrust和EFF等组织发起,目的就是向网站自动签发和管理免费证书,以便加速互联网由HTTP过渡到HTTPS,目前Facebook等大公司开始加入赞助行列。

Let’s Encrypt已经得了 IdenTrust 的交叉签名,这意味着其证书现在已经可以被Mozilla、Google、Microsoft和Apple等主流的浏览器所信任,你只需要在Web 服务器证书链中配置交叉签名,浏览器客户端会自动处理好其它的一切,Let’s Encrypt安装简单,未来大规模采用可能性非常大。

方案

Let’s Encrypt 分为 StandanloneWebroot 两种认证方式,主要区别在于:

  1. Standalone 的认证方式需要暂时占用服务器的 80 或者 443 端口,来进行获取和更新证书的操作。这意味着网站必须下线才行。
  2. Webroot 认证方式需要在域名配置文件里 server.conf (监听 80 端口那部分)中,添加一个通配规则,使得 certbot 可以生成一个特定的验证文件,同时让之后 Let’s Encrypt 的验证服务器发起的 http-01 请求可以验证到对应文件。

就目前来说我属于比较懒的一类人,目前暂时忍受住了临时下线的问题(网站下线10s左右),standalone较为简单,遂使用了 standalone 的方式。

例如首次认证test.kelu.org这个域名:

docker run -it --rm --name certbot \
  -p 80:80 \
  -v "$(pwd)/data:/etc/letsencrypt" \
  -v "$(pwd)/datalib:/var/lib/letsencrypt" \
  certbot/certbot certonly \
  --standalone \
  --email xxx@xxx.org --agree-tos \
  -d test.kelu.org

便在当前目录下的data文件夹里生成好了证书。

证书有三个月的有效期,此时运行renew命令即可续约:

docker run -it --rm --name certbot \
  -p 80:80 \
  -v "$(pwd)/data:/etc/letsencrypt" \
  -v "$(pwd)/datalib:/var/lib/letsencrypt" \
  certbot/certbot renew

nginx相关配置

因为一切都是容器化,nginx的配置也固化在文件中,下面是我的docker-compose.yml配置参考:

  nginx:
    image: openresty/openresty:alpine
    restart: always
    volumes:
      - ./:/var/www/html:rw
      - ./docker/letsencrypt/data:/etc/letsencrypt:rw
      - ./docker/openresty/conf.d:/etc/nginx/conf.d:rw
      - ./docker/openresty/conf/nginx.conf:/usr/local/openresty/nginx/conf/nginx.conf:rw
      - ./docker/log:/log:rw
    links:
      - "php"
    ports:
      - "80:80"
      - "443:443"

nginx 的配置如下:

server {
    listen       443;
    server_name  test.kelu.org;

    access_log /log/test.access.log;
    error_log  /log/test.error.log;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/test.kelu.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/test.kelu.org/privkey.pem;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers AESGCM:ALL:!DH:!EXPORT:!RC4:+HIGH:!MEDIUM:!LOW:!aNULL:!eNULL;
    ssl_prefer_server_ciphers on;

    root         /var/www/html/;

    error_page 404 500 502 503 504 /index.html;
}

改进

本文是一个简单初级的生成证书的方式,可快速部署。

目前有几个待改进的点:

  1. 生成证书需要占用80、443端口,意味着当前业务必须停止。
  2. 证书 renew 也需要停止当前业务。
  3. 目前有以dns认证的方式获取证书,更加方便。

参考资料


Docker on Windows Operation not permitted

先前分享了一个容器化的开发环境——kelvinblood/docker-lnmp,在 mac 下运行无碍,可是跑到Windows下运行的时候,sock 的文件映射就出了问题:

2018/09/17 02:39:54 [crit] 6#6: *2 connect() to unix:/sock/www.sock failed (2: No such file or directory) while connecting to upstream, client: 10.0.75.1, server: , request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/sock/www.sock:", host: "10.0.75.2:8000"

让我疑惑的是,我还有很多的映射,都是ok的,比如log,怎么单单就这个 sock 出了问题?

谷歌了一番,发现 mongo 项目里也有很多人吐槽这个情况,看来并不是我一个人的问题。众多issue里发现了这个靠谱的中文答案:win10下部署报错:Operation not permitted, terminating #7

windows下只能使用volume,不能直接bind磁盘。

创建volume
docker volume create mongodata
docker volume create redisdata
docker volume create logsdata

将docker-compose.yml修改如下
version: "3.3"
...
    image: redis:4.0.6
    command: redis-server --appendonly yes
    volumes:
      - type: volume
        source: redisdata
        target: /data
...

# 一定要声明volumes
volumes:
  redisdata:
    external:
      name: redisdata
      
      
删除production.js中的db配置
运行docker-compose up -d

确实如此。我的修改在这个提交里可以参考:

[bugfix] use sock must use bind type for windows mount volume in dock…


腾讯 23 岁安全工程师因黑入新加坡一酒店 Wi-Fi,或判狱三年

一位中国公民在新加坡出席一次网络安全会议期间,决定黑入他下榻酒店的WiFi。

img

腾讯的23岁安全工程师郑杜涛(音译:Zheng Dutao)很想找出飞龙酒店(Fragrance Hotel)一家分店的WiFi服务器有没有安全漏洞,结果吃上了官司,真是好奇心害死猫。

郑某成功地黑入了这台服务器,并在一篇名为“钻新加坡酒店的空子”的帖子中撰文介绍了始末,他还公布了酒店管理员使用的服务器密码。结果这篇博文引起了新加坡网络安全局(CSA)的注意。

周一(9月24日),郑某因此违法行为在新加坡国家法院被罚5000美元。他对这一项罪名供认不讳:有意披露密码,未经授权擅自访问属于飞龙酒店的数据。法院在对他判决时考虑到了一起类似的罪状。

郑某上个月抵达新加坡参加“夺旗”(Capture the Flag)比赛,这项比赛是在洲际酒店举行的网络安全会议上举办的。参赛的安全专家们各自展示黑客攻击和反黑客能力。

郑某在8月27日入住了位于武吉士的飞龙酒店。一天后,他很好奇,想知道这家酒店的WiFi服务器有没有可能存在安全漏洞。通过谷歌,他成功地搜索到了这家酒店WiFi系统的默认用户ID和密码。

郑某连接到酒店的WiFi网关后,在接下来的三天内执行脚本、解密文件和破解密码,然后闯入了酒店WiFi服务器的数据库。

酒店使用的这款服务器存在一个安全漏洞,郑某钻了该漏洞的空子,最终闯入了服务器。他还试图访问飞龙酒店小印度分店的WiFi服务器,但结果失败了。

郑某在其个人博客上记述了他的攻击步骤。他在博文中公布了飞龙酒店WiFi服务器的管理员密码,还在WhatsApp群聊中共享了那篇博文的URL链接。