Prohoster > Blog > quản lý > Hướng tới tự động hóa việc phát hành SSL

Hướng tới tự động hóa việc phát hành SSL

Chúng ta thường phải làm việc với chứng chỉ SSL. Hãy nhớ lại quá trình tạo và cài đặt chứng chỉ (trong trường hợp chung đối với hầu hết).

  • Tìm nhà cung cấp (trang web nơi chúng tôi có thể mua SSL).
  • Tạo CSR.
  • Gửi nó cho nhà cung cấp của bạn.
  • Xác minh quyền sở hữu tên miền.
  • Có được một giấy chứng nhận.
  • Chuyển đổi chứng chỉ sang biểu mẫu được yêu cầu (tùy chọn). Ví dụ: từ pem đến PKCS #12.
  • Cài đặt chứng chỉ trên máy chủ web.

Tương đối nhanh, không phức tạp và dễ hiểu. Tùy chọn này khá phù hợp nếu chúng tôi có tối đa mười dự án. Điều gì sẽ xảy ra nếu có nhiều môi trường hơn và chúng có ít nhất ba môi trường? Phát triển - dàn dựng - sản xuất cổ điển. Trong trường hợp này, đáng suy nghĩ về việc tự động hóa quá trình này. Tôi đề xuất tìm hiểu sâu hơn một chút về vấn đề và tìm ra giải pháp giúp giảm thiểu hơn nữa thời gian dành cho việc tạo và duy trì chứng chỉ. Bài viết sẽ bao gồm một phân tích về vấn đề và một hướng dẫn nhỏ để lặp lại.

Hãy để tôi đặt chỗ trước: chuyên môn chính của công ty chúng tôi là .net, và theo đó, IIS và các sản phẩm liên quan đến Windows khác. Do đó, máy khách ACME và mọi hành động đối với nó cũng sẽ được mô tả từ quan điểm sử dụng Windows.

Điều này có liên quan đến ai và một số dữ liệu ban đầu

Công ty K do tác giả đại diện. URL (ví dụ): company.tld

Dự án X là một trong những dự án của chúng tôi, khi thực hiện dự án này, tôi đã đi đến kết luận rằng chúng tôi vẫn cần hướng tới tiết kiệm thời gian tối đa khi làm việc với chứng chỉ. Dự án này có bốn môi trường: dev, test, staging và production. Nhà phát triển và thử nghiệm thuộc về phía chúng tôi, việc dàn dựng và sản xuất thuộc về phía khách hàng.

Điểm đặc biệt của dự án là nó có một số lượng lớn các mô-đun có sẵn dưới dạng tên miền phụ.

Tức là chúng ta có hình ảnh sau:

Dev
Thử nghiệm
Dàn dựng
Sản lượng

projectX.dev.company.tld
projectX.test.company.tld
dàn dựng.projectX.tld
dự ánX.tld

module1.projectX.dev.company.tld
module1.projectX.test.company.tld
module1.staging.projectX.tld
module1.projectX.tld

module2.projectX.dev.company.tld
module2.projectX.test.company.tld
module2.staging.projectX.tld
module2.projectX.tld

...
...
...
...

moduleN.projectX.dev.company.tld
moduleN.projectX.test.company.tld
moduleN.staging.projectX.tld
moduleN.projectX.tld

Để sản xuất, chứng chỉ ký tự đại diện đã mua sẽ được sử dụng, không có câu hỏi nào phát sinh ở đây. Nhưng nó chỉ bao gồm cấp độ đầu tiên của tên miền phụ. Theo đó, nếu có chứng chỉ cho *.projectX.tld thì nó sẽ hoạt động cho staging.projectX.tld, nhưng không hoạt động cho module1.staging.projectX.tld. Nhưng không hiểu sao tôi lại không muốn mua một cái riêng.

Và điều này chỉ dựa trên ví dụ về một dự án của một công ty. Và tất nhiên là có nhiều hơn một dự án.

Những lý do phổ biến để mọi người giải quyết vấn đề này trông giống như sau:

  • Gần đây Google đề xuất giảm thời hạn hiệu lực tối đa của chứng chỉ SSL. Với tất cả những hậu quả.
  • Tạo điều kiện thuận lợi cho quá trình cấp và duy trì SSL cho nhu cầu nội bộ của các dự án và toàn bộ công ty.
  • Lưu trữ tập trung các bản ghi chứng chỉ, giải quyết một phần vấn đề xác minh tên miền bằng DNS và gia hạn tự động sau đó, đồng thời giải quyết vấn đề về lòng tin của khách hàng. Tuy nhiên, CNAME trên máy chủ của đối tác/công ty biểu diễn vẫn đáng tin cậy hơn so với tài nguyên của bên thứ ba.
  • Chà, cuối cùng, trong trường hợp này, cụm từ “thà có còn hơn không có” hoàn toàn phù hợp.

Chọn nhà cung cấp SSL và các bước chuẩn bị

Trong số các tùy chọn có sẵn cho chứng chỉ SSL miễn phí, cloudflare và letsencrypt đã được xem xét. DNS cho dự án này (và một số dự án khác) được lưu trữ bởi cloudflare, nhưng tôi không phải là người thích sử dụng chứng chỉ của họ. Vì vậy, người ta đã quyết định sử dụng letsencrypt.
Để tạo chứng chỉ SSL ký tự đại diện, bạn cần xác nhận quyền sở hữu tên miền. Quy trình này bao gồm việc tạo một số bản ghi DNS (TXT hoặc CNAME), sau đó xác minh nó khi cấp chứng chỉ. Linux có một tiện ích - certbot, cho phép bạn tự động hóa một phần (hoặc hoàn toàn đối với một số nhà cung cấp DNS) quá trình này. Dành cho Windows từ được tìm thấy và xác minh Các tùy chọn khách hàng ACME mà tôi đã quyết định WinACME.

Và bản ghi cho tên miền đã được tạo, chúng ta hãy chuyển sang tạo chứng chỉ:

Hướng tới tự động hóa việc phát hành SSL

Chúng tôi quan tâm đến kết luận cuối cùng, cụ thể là các tùy chọn có sẵn để xác nhận quyền sở hữu tên miền nhằm cấp chứng chỉ ký tự đại diện:

  1. Tạo bản ghi DNS theo cách thủ công (không hỗ trợ cập nhật tự động)
  2. Tạo bản ghi DNS bằng máy chủ acme-dns (bạn có thể đọc thêm về đây.
  3. Tạo bản ghi DNS bằng tập lệnh của riêng bạn (tương tự như plugin cloudflare cho certbot).

Thoạt nhìn, điểm thứ ba khá phù hợp, nhưng nếu nhà cung cấp DNS không hỗ trợ chức năng này thì sao? Nhưng chúng ta cần một trường hợp tổng quát. Và trường hợp chung là bản ghi CNAME, vì mọi người đều hỗ trợ chúng. Do đó, chúng tôi dừng lại ở điểm 2 và tiến hành định cấu hình máy chủ ACME-DNS của mình.

Thiết lập máy chủ ACME-DNS và quy trình cấp chứng chỉ

Ví dụ: tôi đã tạo miền 2nd.pp.ua và sẽ sử dụng miền này trong tương lai.

Yêu cầu bắt buộc Để máy chủ hoạt động chính xác cần tạo các bản ghi NS và A cho miền của nó. Và khoảnh khắc khó chịu đầu tiên mà tôi gặp phải là cloudflare (ít nhất là ở chế độ sử dụng miễn phí) không cho phép bạn tạo đồng thời bản ghi NS và A cho cùng một máy chủ. Không phải đây là một vấn đề, nhưng trong ràng buộc thì điều đó là có thể. Bộ phận hỗ trợ trả lời rằng bảng điều khiển của họ không cho phép làm điều này. Không vấn đề gì, hãy tạo hai bản ghi:

acmens.2nd.pp.ua. IN A 35.237.128.147
acme.2nd.pp.ua. IN NS acmens.2nd.pp.ua.

Ở giai đoạn này, chủ nhà của chúng tôi nên giải quyết acmens.2nd.pp.ua.

$ ping acmens.2nd.pp.ua
PING acmens.2nd.pp.ua (35.237.128.147) 56(84) bytes of data

Nhưng acme.2nd.pp.ua nó sẽ không giải quyết được vì máy chủ DNS phục vụ nó chưa chạy.

Các bản ghi đã được tạo, chúng ta tiến hành thiết lập và khởi chạy máy chủ ACME-DNS. Nó sẽ tồn tại trên máy chủ Ubuntu của tôi trong docker container, nhưng bạn có thể chạy nó ở bất cứ nơi nào có golang. Windows cũng khá phù hợp nhưng mình vẫn thích server Linux hơn.

Tạo các thư mục và tập tin cần thiết:

$ mkdir config
$ mkdir data
$ touch config/config.cfg

Hãy sử dụng vim với trình soạn thảo văn bản yêu thích của bạn và dán mẫu vào config.cfg cấu hình.

Để hoạt động thành công, việc sửa các phần chung và api là đủ:

[general]
listen = "0.0.0.0:53"
protocol = "both"
domain = "acme.2nd.pp.ua"
nsname = "acmens.2nd.pp.ua" 
nsadmin = "admin.2nd.pp.ua" 
records = 
    "acme.2nd.pp.ua. A 35.237.128.147",
    "acme.2nd.pp.ua. NS acmens.2nd.pp.ua.",                                                                                                                                                                                                  ]
...
[api]
...
tls = "letsencrypt"
…

Ngoài ra, nếu muốn, chúng tôi sẽ tạo một tệp docker-compose trong thư mục dịch vụ chính:

version: '3.7'
services:
  acmedns:
    image: joohoi/acme-dns:latest
    ports:
      - "443:443"
      - "53:53"
      - "53:53/udp"
      - "80:80"
    volumes:
      - ./config:/etc/acme-dns:ro
      - ./data:/var/lib/acme-dns

Sẵn sàng. Bạn có thể chạy nó.

$ docker-compose up -d

Ở giai đoạn này, chủ nhà nên bắt đầu giải quyết acme.2nd.pp.uavà 404 xuất hiện trên https://acme.2nd.pp.ua

$ ping acme.2nd.pp.ua
PING acme.2nd.pp.ua (35.237.128.147) 56(84) bytes of data.

$ curl https://acme.2nd.pp.ua
404 page not found

Nếu điều này không xuất hiện - docker logs -f <container_name> để giúp đỡ, may mắn thay, nhật ký khá dễ đọc.

Chúng ta có thể bắt đầu tạo chứng chỉ. Mở powershell với tư cách quản trị viên và chạy winacme. Chúng tôi quan tâm đến cuộc bầu cử:

  • M: Tạo chứng chỉ mới (tùy chọn đầy đủ)
  • 2: Nhập thủ công
  • 2: [dns-01] Tạo bản ghi xác minh bằng acme-dns (https://github.com/joohoi/acme-dns)
  • Khi được hỏi về liên kết đến máy chủ ACME-DNS, hãy nhập URL của máy chủ đã tạo (https) vào câu trả lời. URL của máy chủ acme-dns: https://acme.2nd.pp.ua

Khi mở đầu, máy khách đưa ra một bản ghi cần được thêm vào máy chủ DNS hiện có (thủ tục một lần):

[INFO] Creating new acme-dns registration for domain 1nd.pp.ua

Domain:              1nd.pp.ua
Record:               _acme-challenge.1nd.pp.ua
Type:                   CNAME
Content:              c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.
Note:                   Some DNS control panels add the final dot automatically.
                           Only one is required.

Hướng tới tự động hóa việc phát hành SSL

Chúng tôi tạo bản ghi cần thiết và đảm bảo rằng nó được tạo chính xác:

Hướng tới tự động hóa việc phát hành SSL

$ dig CNAME _acme-challenge.1nd.pp.ua +short
c82a88a5-499f-464f-96e4-be7f606a3b47.acme.2nd.pp.ua.

Chúng tôi xác nhận rằng chúng tôi đã tạo mục nhập bắt buộc trong winacme và tiếp tục quá trình tạo chứng chỉ:

Hướng tới tự động hóa việc phát hành SSL

Cách sử dụng certbot với tư cách khách hàng được mô tả đây.

Việc này hoàn tất quá trình tạo chứng chỉ; bạn có thể cài đặt nó trên máy chủ web và sử dụng nó. Nếu khi tạo chứng chỉ, bạn cũng tạo một tác vụ trong bộ lập lịch thì trong tương lai, quá trình gia hạn chứng chỉ sẽ tự động diễn ra.

Nguồn: www.habr.com

Thêm một lời nhận xét