W stronę automatyzacji wydawania certyfikatów SSL

Dość często musimy pracować z certyfikatami SSL. Przypomnijmy sobie proces tworzenia i instalacji certyfikatu (w większości przypadków w ogólnym przypadku).

• Znajdź dostawcę (stronę, na której możemy kupić SSL).
• Generuj CSR.
• Wyślij to do swojego dostawcy.
• Zweryfikuj własność domeny.
• Uzyskać certyfikat.
• Konwertuj certyfikat do wymaganej formy (opcjonalnie). Na przykład z pem na PKCS #12.
• Zainstaluj certyfikat na serwerze WWW.

Stosunkowo szybko, nieskomplikowane i zrozumiałe. Ta opcja jest całkiem odpowiednia, jeśli mamy maksymalnie dziesięć projektów. A co jeśli jest ich więcej i mają co najmniej trzy środowiska? Klasyczny deweloper – inscenizacja – produkcja. W takim przypadku warto pomyśleć o automatyzacji tego procesu. Proponuję zagłębić się w problem i znaleźć rozwiązanie, które jeszcze bardziej zminimalizuje czas poświęcany na tworzenie i utrzymywanie certyfikatów. W artykule będzie zawarta analiza problemu oraz mały poradnik dotyczący powtórek.

Pozwolę sobie dokonać rezerwacji z wyprzedzeniem: główną specjalizacją naszej firmy jest .net, a co za tym idzie IIS i inne produkty powiązane z Windows. Dlatego też klient ACME i wszystkie działania na nim zostaną opisane również z punktu widzenia korzystania z systemu Windows.

Dla kogo jest to istotne i niektóre dane wstępne

Firma K reprezentowana przez autora. Adres URL (na przykład): firma.tld

Projekt X to jeden z naszych projektów, podczas pracy nad którym doszedłem do wniosku, że musimy jeszcze dążyć do maksymalnej oszczędności czasu podczas pracy z certyfikatami. Ten projekt ma cztery środowiska: deweloperskie, testowe, staging i produkcyjne. Dev i test są po naszej stronie, inscenizacja i produkcja są po stronie klienta.

Cechą szczególną projektu jest to, że posiada dużą liczbę modułów dostępnych jako subdomeny.

Oznacza to, że mamy następujący obraz:

dev
Testowanie
Inscenizacja
Produkcja

projektX.dev.company.tld
projektX.test.firma.tld
staging.projectX.tld
projektX.tld

moduł1.projectX.dev.company.tld
moduł1.projektX.test.firma.tld
moduł1.staging.projectX.tld
moduł1.projektX.tld

moduł2.projectX.dev.company.tld
moduł2.projektX.test.firma.tld
moduł2.staging.projectX.tld
moduł2.projektX.tld

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

modułN.projectX.dev.company.tld
modułN.projectX.test.company.tld
modułN.staging.projectX.tld
modułN.projectX.tld

Do produkcji wykorzystywany jest zakupiony certyfikat wieloznaczny, tutaj nie pojawiają się żadne pytania. Ale obejmuje tylko pierwszy poziom subdomeny. Odpowiednio, jeśli istnieje certyfikat dla *.projectX.tld, będzie on działał dla staging.projectX.tld, ale nie dla module1.staging.projectX.tld. Ale jakoś nie chcę kupować osobnego.

I to tylko na przykładzie jednego projektu jednej firmy. I oczywiście jest więcej niż jeden projekt.

Najczęstsze powody, dla których wszyscy zajmują się tym problemem, wyglądają mniej więcej tak:

• тносительно недавно Google zaproponował skrócenie maksymalnego okresu ważności certyfikatów SSL. Ze wszystkimi konsekwencjami.
• Ułatwienie procesu wydawania i utrzymywania protokołu SSL na potrzeby wewnętrzne projektów i całej firmy.
• Scentralizowane przechowywanie rekordów certyfikatów, co częściowo rozwiązuje problem weryfikacji domeny za pomocą DNS i późniejszego automatycznego odnawiania, a także rozwiązuje problem zaufania klientów. Mimo to rekord CNAME na serwerze firmy partnerskiej/wykonawcy jest bardziej godny zaufania niż w zasobie strony trzeciej.
• No i wreszcie w tym przypadku stwierdzenie „lepiej mieć, niż nie mieć” pasuje idealnie.

Wybór dostawcy SSL i kroki przygotowawcze

Wśród dostępnych opcji bezpłatnych certyfikatów SSL rozważano cloudflare i letsencrypt. DNS dla tego (i niektórych innych projektów) jest hostowany przez Cloudflare, ale nie jestem fanem używania ich certyfikatów. Dlatego zdecydowano się użyć letsencrypt.
Aby utworzyć wieloznaczny certyfikat SSL, musisz potwierdzić własność domeny. Procedura ta polega na utworzeniu jakiegoś rekordu DNS (TXT lub CNAME), a następnie zweryfikowaniu go przy wydawaniu certyfikatu. Linux ma narzędzie - certbot, co pozwala częściowo (lub całkowicie w przypadku niektórych dostawców DNS) zautomatyzować ten proces. Dla systemu Windows od znalezione i sprawdzone Opcje klienta ACME, na które się zdecydowałem WinACME.

I rekord dla domeny został utworzony, przejdźmy do tworzenia certyfikatu:

Nas interesuje ostatni wniosek, a mianowicie dostępne opcje potwierdzenia własności domeny w celu wystawienia certyfikatu wieloznacznego:

1. Twórz rekordy DNS ręcznie (automatyczna aktualizacja nie jest obsługiwana)
2. Tworzenie rekordów DNS za pomocą serwera acme-dns (więcej możesz przeczytać na temat tutaj.
3. Tworzenie rekordów DNS za pomocą własnego skryptu (podobnie jak wtyczka cloudflare dla certbota).

Na pierwszy rzut oka trzeci punkt jest całkiem odpowiedni, ale co, jeśli dostawca DNS nie obsługuje tej funkcjonalności? Ale potrzebujemy przypadku ogólnego. Ogólnym przypadkiem są rekordy CNAME, ponieważ wszyscy je obsługują. Dlatego zatrzymujemy się w punkcie 2 i przechodzimy do konfiguracji naszego serwera ACME-DNS.

Konfigurowanie serwera ACME-DNS i procesu wydawania certyfikatów

Na przykład stworzyłem domenę 2nd.pp.ua i będę z niej korzystać w przyszłości.

Wymaganie obowiązkowe Aby serwer działał poprawnie konieczne jest utworzenie rekordów NS i A dla jego domeny. I pierwszym nieprzyjemnym momentem, z jakim się spotkałem, jest to, że cloudflare (przynajmniej w trybie darmowego użytkowania) nie pozwala na jednoczesne utworzenie rekordu NS i A dla tego samego hosta. Nie żeby to był problem, ale w bindowaniu jest to możliwe. Support odpowiedział, że ich panel na to nie pozwala. Nie ma problemu, utwórzmy dwa rekordy:

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

Na tym etapie nasz host powinien rozwiązać problem acmens.2nd.pp.ua.

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

a tutaj acme.2nd.pp.ua nie zostanie rozwiązany, ponieważ serwer DNS, który go obsługuje, jeszcze nie działa.

Rekordy zostały utworzone, przystępujemy do konfiguracji i uruchomienia serwera ACME-DNS. Będzie żyć na moim serwerze Ubuntu w doker kontener, ale możesz go uruchomić wszędzie tam, gdzie dostępny jest golang. Windows jest również całkiem odpowiedni, ale nadal wolę serwer Linux.

Utwórz niezbędne katalogi i pliki:

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

Użyjmy vima z twoim ulubionym edytorem tekstu i wklejmy próbkę do config.cfg konfiguracja.

Aby operacja przebiegła pomyślnie, wystarczy poprawić sekcje ogólne i API:

[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"
…

Ponadto, jeśli to konieczne, utworzymy plik docker-compose w głównym katalogu usług:

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

Gotowy. Możesz to uruchomić.

$ docker-compose up -d

Na tym etapie host powinien zacząć rozwiązywać problemy acme.2nd.pp.uai pojawia się komunikat 404 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

Jeśli to się nie pojawi - docker logs -f <container_name> żeby pomóc, na szczęście logi są w miarę czytelne.

Możemy przystąpić do tworzenia certyfikatu. Otwórz PowerShell jako administrator i uruchom Wincme. Nas interesują wybory:

• M: Utwórz nowy certyfikat (pełne opcje)
• 2:Wprowadzanie ręczne
• 2: [dns-01] Utwórz rekordy weryfikacyjne za pomocą acme-dns (https://github.com/joohoi/acme-dns)
• Na pytanie o link do serwera ACME-DNS w odpowiedzi wpisz adres URL utworzonego serwera (https). Adres URL serwera acme-dns: https://acme.2nd.pp.ua

Podczas otwarcia klient wystawia rekord, który należy dodać do istniejącego serwera DNS (procedura jednorazowa):

[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.

Tworzymy niezbędny zapis i upewniamy się, że został on utworzony prawidłowo:

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

Potwierdzamy, że utworzyliśmy wymagany wpis w wincme i kontynuujemy proces tworzenia certyfikatu:

Opisano, jak używać certbota jako klienta tutaj.

Na tym kończy się proces tworzenia certyfikatu, można go zainstalować na serwerze WWW i używać. Jeśli podczas tworzenia certyfikatu utworzysz także zadanie w harmonogramie, to w przyszłości proces odnowienia certyfikatu będzie przebiegał automatycznie.

Źródło: www.habr.com