എസ്എസ്എൽ ഇഷ്യുവിന്റെ ഓട്ടോമേഷനിലേക്ക്

പലപ്പോഴും ഞങ്ങൾ SSL സർട്ടിഫിക്കറ്റുകളുമായി പ്രവർത്തിക്കേണ്ടതുണ്ട്. ഒരു സർട്ടിഫിക്കറ്റ് സൃഷ്ടിക്കുന്നതിനും ഇൻസ്റ്റാൾ ചെയ്യുന്നതിനുമുള്ള പ്രക്രിയ നമുക്ക് ഓർക്കാം (മിക്കവാറും പൊതുവെ).

• ഒരു ദാതാവിനെ കണ്ടെത്തുക (ഞങ്ങൾക്ക് SSL വാങ്ങാൻ കഴിയുന്ന ഒരു സൈറ്റ്).
• CSR സൃഷ്ടിക്കുക.
• ഇത് നിങ്ങളുടെ ദാതാവിന് അയയ്ക്കുക.
• ഡൊമെയ്ൻ ഉടമസ്ഥത പരിശോധിക്കുക.
• ഒരു സർട്ടിഫിക്കറ്റ് നേടുക.
• ആവശ്യമായ ഫോമിലേക്ക് സർട്ടിഫിക്കറ്റ് പരിവർത്തനം ചെയ്യുക (ഓപ്ഷണൽ). ഉദാഹരണത്തിന്, പെം മുതൽ PKCS #12 വരെ.
• വെബ് സെർവറിൽ സർട്ടിഫിക്കറ്റ് ഇൻസ്റ്റാൾ ചെയ്യുക.

താരതമ്യേന വേഗതയുള്ളതും സങ്കീർണ്ണമല്ലാത്തതും മനസ്സിലാക്കാവുന്നതുമാണ്. ഞങ്ങൾക്ക് പരമാവധി പത്ത് പ്രോജക്ടുകൾ ഉണ്ടെങ്കിൽ ഈ ഓപ്ഷൻ തികച്ചും അനുയോജ്യമാണ്. അവയിൽ കൂടുതൽ ഉണ്ടെങ്കിൽ, അവർക്ക് കുറഞ്ഞത് മൂന്ന് പരിതസ്ഥിതികളെങ്കിലും ഉണ്ടെങ്കിലോ? ക്ലാസിക് ദേവ് - സ്റ്റേജിംഗ് - പ്രൊഡക്ഷൻ. ഈ സാഹചര്യത്തിൽ, ഈ പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനെക്കുറിച്ച് ചിന്തിക്കേണ്ടതാണ്. സർ‌ട്ടിഫിക്കറ്റുകൾ‌ സൃഷ്‌ടിക്കുന്നതിനും പരിപാലിക്കുന്നതിനും ചെലവഴിക്കുന്ന സമയം കൂടുതൽ‌ കുറയ്‌ക്കുന്ന ഒരു പരിഹാരം കണ്ടെത്താനും പ്രശ്‌നത്തിൽ‌ അൽപ്പം ആഴത്തിൽ‌ പരിശോധിക്കാനും ഞാൻ‌ നിർദ്ദേശിക്കുന്നു. ലേഖനത്തിൽ പ്രശ്നത്തിന്റെ വിശകലനവും ആവർത്തനത്തിനുള്ള ഒരു ചെറിയ ഗൈഡും അടങ്ങിയിരിക്കും.

ഞാൻ മുൻകൂട്ടി ഒരു റിസർവേഷൻ നടത്തട്ടെ: ഞങ്ങളുടെ കമ്പനിയുടെ പ്രധാന സ്പെഷ്യലൈസേഷൻ .net ആണ്, അതനുസരിച്ച്, IIS ഉം മറ്റ് Windows അനുബന്ധ ഉൽപ്പന്നങ്ങളും. അതിനാൽ, ACME ക്ലയന്റും അതിനുള്ള എല്ലാ പ്രവർത്തനങ്ങളും വിൻഡോസ് ഉപയോഗിക്കുന്നതിന്റെ വീക്ഷണകോണിൽ നിന്ന് വിവരിക്കും.

ആർക്കാണ് ഇത് പ്രസക്തവും ചില പ്രാരംഭ ഡാറ്റയും

രചയിതാവ് പ്രതിനിധീകരിക്കുന്ന കമ്പനി കെ. URL (ഉദാഹരണത്തിന്): company.tld

പ്രൊജക്‌റ്റ് എക്‌സ് ഞങ്ങളുടെ പ്രോജക്‌റ്റുകളിൽ ഒന്നാണ്, അതിൽ പ്രവർത്തിക്കുമ്പോൾ, സർട്ടിഫിക്കറ്റുകൾക്കൊപ്പം പ്രവർത്തിക്കുമ്പോൾ പരമാവധി സമയ ലാഭത്തിലേക്ക് നീങ്ങേണ്ടതുണ്ടെന്ന നിഗമനത്തിൽ ഞാൻ എത്തി. ഈ പ്രോജക്റ്റിന് നാല് പരിതസ്ഥിതികളുണ്ട്: ദേവ്, ടെസ്റ്റ്, സ്റ്റേജിംഗ്, പ്രൊഡക്ഷൻ. ദേവും ടെസ്റ്റും ഞങ്ങളുടെ ഭാഗത്താണ്, സ്റ്റേജിംഗും പ്രൊഡക്ഷനും ക്ലയന്റ് ഭാഗത്താണ്.

ഉപഡൊമെയ്‌നുകളായി ലഭ്യമായ ധാരാളം മൊഡ്യൂളുകൾ ഇതിന് ഉണ്ട് എന്നതാണ് പദ്ധതിയുടെ ഒരു പ്രത്യേകത.

അതായത്, ഞങ്ങൾക്ക് ഇനിപ്പറയുന്ന ചിത്രം ഉണ്ട്:

ദേവ്
പരിശോധന
സ്റ്റേജിംഗ്
പ്രൊഡക്ഷൻ

projectX.dev.company.tld
projectX.test.company.tld
staging.projectX.tld
projectX.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

ഉൽപ്പാദനത്തിനായി, വാങ്ങിയ വൈൽഡ്കാർഡ് സർട്ടിഫിക്കറ്റ് ഉപയോഗിക്കുന്നു, ഇവിടെ ചോദ്യങ്ങളൊന്നും ഉണ്ടാകില്ല. എന്നാൽ ഇത് ഉപഡൊമെയ്‌നിന്റെ ആദ്യ തലം മാത്രം ഉൾക്കൊള്ളുന്നു. അതനുസരിച്ച്, *.projectX.tld എന്നതിന് ഒരു സർട്ടിഫിക്കറ്റ് ഉണ്ടെങ്കിൽ, അത് staging.projectX.tld-ന് പ്രവർത്തിക്കും, എന്നാൽ module1.staging.projectX.tld-ന് വേണ്ടിയല്ല. എന്നാൽ എങ്ങനെയെങ്കിലും ഒരു പ്രത്യേകം വാങ്ങാൻ ഞാൻ ആഗ്രഹിക്കുന്നില്ല.

ഇത് ഒരു കമ്പനിയുടെ ഒരു പ്രോജക്റ്റിന്റെ ഉദാഹരണത്തെ മാത്രം അടിസ്ഥാനമാക്കിയുള്ളതാണ്. കൂടാതെ, തീർച്ചയായും, ഒന്നിൽ കൂടുതൽ പദ്ധതികളുണ്ട്.

ഈ പ്രശ്നം പരിഹരിക്കാനുള്ള എല്ലാവർക്കും പൊതുവായ കാരണങ്ങൾ ഇതുപോലെയാണ്:

• അടുത്തിടെ SSL സർട്ടിഫിക്കറ്റുകളുടെ പരമാവധി സാധുത കാലയളവ് കുറയ്ക്കാൻ Google നിർദ്ദേശിച്ചു. എല്ലാ അനന്തരഫലങ്ങളോടും കൂടി.
• പ്രോജക്റ്റുകളുടെയും കമ്പനിയുടെയും മൊത്തത്തിലുള്ള ആന്തരിക ആവശ്യങ്ങൾക്കായി എസ്എസ്എൽ നൽകുന്നതിനും പരിപാലിക്കുന്നതിനുമുള്ള പ്രക്രിയ സുഗമമാക്കുക.
• സർട്ടിഫിക്കറ്റ് രേഖകളുടെ കേന്ദ്രീകൃത സംഭരണം, ഇത് DNS ഉപയോഗിച്ചുള്ള ഡൊമെയ്ൻ സ്ഥിരീകരണത്തിന്റെ പ്രശ്‌നവും തുടർന്നുള്ള സ്വയമേവ പുതുക്കലും ഭാഗികമായി പരിഹരിക്കുന്നു, കൂടാതെ ക്ലയന്റ് വിശ്വാസത്തിന്റെ പ്രശ്‌നവും പരിഹരിക്കുന്നു. എന്നിരുന്നാലും, ഒരു മൂന്നാം കക്ഷി റിസോഴ്സിനേക്കാൾ ഒരു പങ്കാളിയുടെ/പെർഫോമർ കമ്പനിയുടെ സെർവറിലെ ഒരു CNAME കൂടുതൽ വിശ്വസനീയമാണ്.
• ശരി, ഒടുവിൽ, ഈ സാഹചര്യത്തിൽ "ഇല്ലാത്തതിനേക്കാൾ നല്ലത്" എന്ന വാചകം തികച്ചും യോജിക്കുന്നു.

ഒരു SSL ദാതാവിനെ തിരഞ്ഞെടുക്കുന്നതും തയ്യാറെടുപ്പ് ഘട്ടങ്ങളും

സൗജന്യ എസ്എസ്എൽ സർട്ടിഫിക്കറ്റുകൾക്കായി ലഭ്യമായ ഓപ്ഷനുകളിൽ, ക്ലൗഡ്ഫ്ലെയർ, ലെറ്റ്സെൻക്രിപ്റ്റ് എന്നിവ പരിഗണിച്ചു. ഇതിനുള്ള (കൂടാതെ മറ്റ് ചില പ്രോജക്‌റ്റുകൾ) DNS ഹോസ്റ്റ് ചെയ്‌തിരിക്കുന്നത് ക്ലൗഡ്‌ഫ്ലെയർ ആണ്, എന്നാൽ അവരുടെ സർട്ടിഫിക്കറ്റുകൾ ഉപയോഗിക്കുന്നതിൽ ഞാൻ ഒരു ആരാധകനല്ല. അതിനാൽ, letsencrypt ഉപയോഗിക്കാൻ തീരുമാനിച്ചു.
ഒരു വൈൽഡ്കാർഡ് SSL സർട്ടിഫിക്കറ്റ് സൃഷ്ടിക്കാൻ, നിങ്ങൾ ഡൊമെയ്ൻ ഉടമസ്ഥത സ്ഥിരീകരിക്കേണ്ടതുണ്ട്. ഈ നടപടിക്രമത്തിൽ ചില DNS റെക്കോർഡ് (TXT അല്ലെങ്കിൽ CNAME) സൃഷ്‌ടിക്കുകയും സർട്ടിഫിക്കറ്റ് നൽകുമ്പോൾ അത് സ്ഥിരീകരിക്കുകയും ചെയ്യുന്നു. Linux-ന് ഒരു യൂട്ടിലിറ്റി ഉണ്ട് - certbot, ഇത് നിങ്ങളെ ഭാഗികമായി (അല്ലെങ്കിൽ ചില DNS ദാതാക്കൾക്കായി പൂർണ്ണമായും) ഈ പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യാൻ അനുവദിക്കുന്നു. വിൻഡോസിനായി കണ്ടെത്തി പരിശോധിച്ചു ഞാൻ സ്ഥിരതാമസമാക്കിയ ACME ക്ലയന്റ് ഓപ്ഷനുകൾ WinACME.

ഡൊമെയ്‌നിനായുള്ള റെക്കോർഡ് സൃഷ്‌ടിച്ചു, നമുക്ക് ഒരു സർട്ടിഫിക്കറ്റ് സൃഷ്‌ടിക്കുന്നതിലേക്ക് പോകാം:

അവസാന നിഗമനത്തിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ട്, അതായത്, ഒരു വൈൽഡ്കാർഡ് സർട്ടിഫിക്കറ്റ് നൽകുന്നതിനുള്ള ഡൊമെയ്ൻ ഉടമസ്ഥാവകാശം സ്ഥിരീകരിക്കുന്നതിനുള്ള ലഭ്യമായ ഓപ്ഷനുകൾ:

1. DNS റെക്കോർഡുകൾ സ്വമേധയാ സൃഷ്‌ടിക്കുക (യാന്ത്രിക അപ്‌ഡേറ്റ് പിന്തുണയ്‌ക്കുന്നില്ല)
2. acme-dns സെർവർ ഉപയോഗിച്ച് DNS റെക്കോർഡുകൾ സൃഷ്ടിക്കുന്നു (നിങ്ങൾക്ക് ഇതിനെക്കുറിച്ച് കൂടുതൽ വായിക്കാം ഇവിടെ.
3. നിങ്ങളുടെ സ്വന്തം സ്‌ക്രിപ്റ്റ് ഉപയോഗിച്ച് DNS റെക്കോർഡുകൾ സൃഷ്‌ടിക്കുന്നു (certbot-നുള്ള ക്ലൗഡ്ഫ്ലെയർ പ്ലഗിൻ പോലെ).

ഒറ്റനോട്ടത്തിൽ, മൂന്നാമത്തെ പോയിന്റ് തികച്ചും അനുയോജ്യമാണ്, എന്നാൽ DNS ദാതാവ് ഈ പ്രവർത്തനത്തെ പിന്തുണയ്ക്കുന്നില്ലെങ്കിൽ എന്തുചെയ്യും? എന്നാൽ ഞങ്ങൾക്ക് ഒരു പൊതു കേസ് ആവശ്യമാണ്. എല്ലാവരും പിന്തുണയ്ക്കുന്നതിനാൽ പൊതുവായ കേസ് CNAME റെക്കോർഡുകളാണ്. അതിനാൽ, ഞങ്ങൾ പോയിന്റ് 2 ൽ നിർത്തി ഞങ്ങളുടെ ACME-DNS സെർവർ കോൺഫിഗർ ചെയ്യാൻ പോകുന്നു.

ACME-DNS സെർവറും സർട്ടിഫിക്കറ്റ് നൽകൽ പ്രക്രിയയും സജ്ജീകരിക്കുന്നു

ഉദാഹരണത്തിന്, ഞാൻ 2nd.pp.ua എന്ന ഡൊമെയ്ൻ സൃഷ്ടിച്ചു, ഭാവിയിൽ അത് ഉപയോഗിക്കും.

നിർബന്ധിത ആവശ്യകത സെർവർ ശരിയായി പ്രവർത്തിക്കുന്നതിന്, അതിന്റെ ഡൊമെയ്‌നിനായി NS, A റെക്കോർഡുകൾ സൃഷ്ടിക്കേണ്ടത് ആവശ്യമാണ്. ഞാൻ നേരിട്ട ആദ്യത്തെ അസുഖകരമായ നിമിഷം, ഒരേ ഹോസ്റ്റിനായി ഒരേസമയം ഒരു NS, A റെക്കോർഡ് സൃഷ്‌ടിക്കാൻ ക്ലൗഡ്ഫ്ലെയർ (കുറഞ്ഞത് സൗജന്യ ഉപയോഗ മോഡിൽ) നിങ്ങളെ അനുവദിക്കുന്നില്ല എന്നതാണ്. ഇതൊരു പ്രശ്‌നമാണെന്നല്ല, മറിച്ച് ബന്ധത്തിൽ ഇത് സാധ്യമാണ്. തങ്ങളുടെ പാനൽ ഇത് ചെയ്യാൻ അനുവദിക്കുന്നില്ലെന്ന് പിന്തുണ മറുപടി നൽകി. കുഴപ്പമില്ല, നമുക്ക് രണ്ട് റെക്കോർഡുകൾ സൃഷ്ടിക്കാം:

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

ഈ ഘട്ടത്തിൽ, ഞങ്ങളുടെ ഹോസ്റ്റ് പരിഹരിക്കണം acmens.2nd.pp.ua.

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

പക്ഷേ acme.2nd.pp.ua ഡിഎൻഎസ് സെർവർ ഇതുവരെ പ്രവർത്തിക്കാത്തതിനാൽ അത് പരിഹരിക്കപ്പെടില്ല.

റെക്കോർഡുകൾ സൃഷ്ടിച്ചു, ഞങ്ങൾ ACME-DNS സെർവർ സജ്ജീകരിക്കുന്നതിനും സമാരംഭിക്കുന്നതിനും പോകുന്നു. ഇത് എന്റെ ഉബുണ്ടു സെർവറിൽ ജീവിക്കും ഡോക്കർ കണ്ടെയ്നർ, എന്നാൽ ഗോലാങ് ലഭ്യമായ എവിടെയും നിങ്ങൾക്ക് ഇത് പ്രവർത്തിപ്പിക്കാം. വിൻഡോസും തികച്ചും അനുയോജ്യമാണ്, പക്ഷേ ഞാൻ ഇപ്പോഴും ഒരു ലിനക്സ് സെർവറാണ് ഇഷ്ടപ്പെടുന്നത്.

ആവശ്യമായ ഡയറക്ടറികളും ഫയലുകളും സൃഷ്ടിക്കുക:

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

നിങ്ങളുടെ പ്രിയപ്പെട്ട ടെക്‌സ്‌റ്റ് എഡിറ്ററിനൊപ്പം വിം ഉപയോഗിക്കുകയും config.cfg-ലേക്ക് സാമ്പിൾ ഒട്ടിക്കുകയും ചെയ്യാം കോൺഫിഗറേഷൻ.

വിജയകരമായ പ്രവർത്തനത്തിന്, ജനറൽ, എപിഐ വിഭാഗങ്ങൾ ശരിയാക്കാൻ ഇത് മതിയാകും:

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

കൂടാതെ, വേണമെങ്കിൽ, പ്രധാന സേവന ഡയറക്ടറിയിൽ ഞങ്ങൾ ഒരു ഡോക്കർ-കമ്പോസ് ഫയൽ സൃഷ്ടിക്കും:

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

തയ്യാറാണ്. നിങ്ങൾക്ക് അത് പ്രവർത്തിപ്പിക്കാം.

$ docker-compose up -d

ഈ ഘട്ടത്തിൽ ഹോസ്റ്റ് പരിഹരിക്കാൻ തുടങ്ങണം acme.2nd.pp.ua, കൂടാതെ ഒരു 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

ഇത് ദൃശ്യമാകുന്നില്ലെങ്കിൽ - docker logs -f <container_name> സഹായിക്കാൻ, ഭാഗ്യവശാൽ, ലോഗുകൾ വളരെ വായിക്കാൻ കഴിയും.

നമുക്ക് സർട്ടിഫിക്കറ്റ് ഉണ്ടാക്കാൻ തുടങ്ങാം. അഡ്മിനിസ്ട്രേറ്ററായി പവർഷെൽ തുറന്ന് winacme പ്രവർത്തിപ്പിക്കുക. തിരഞ്ഞെടുപ്പിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ട്:

• എം: പുതിയ സർട്ടിഫിക്കറ്റ് സൃഷ്‌ടിക്കുക (പൂർണ്ണ ഓപ്‌ഷനുകൾ)
• 2:മാനുവൽ ഇൻപുട്ട്
• 2: [dns-01] acme-dns ഉപയോഗിച്ച് സ്ഥിരീകരണ റെക്കോർഡുകൾ സൃഷ്ടിക്കുക (https://github.com/joohoi/acme-dns)
• ACME-DNS സെർവറിലേക്കുള്ള ഒരു ലിങ്കിനെക്കുറിച്ച് ചോദിക്കുമ്പോൾ, ഉത്തരത്തിൽ സൃഷ്ടിച്ച സെർവറിന്റെ (https) URL നൽകുക. acme-dns സെർവറിന്റെ URL: https://acme.2nd.pp.ua

ഓപ്പണിംഗിൽ, നിലവിലുള്ള DNS സെർവറിലേക്ക് ചേർക്കേണ്ട ഒരു റെക്കോർഡ് ക്ലയന്റ് നൽകുന്നു (ഒറ്റത്തവണ നടപടിക്രമം):

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

ഞങ്ങൾ ആവശ്യമായ റെക്കോർഡ് സൃഷ്‌ടിക്കുകയും അത് ശരിയായി സൃഷ്‌ടിച്ചതാണെന്ന് ഉറപ്പാക്കുകയും ചെയ്യുന്നു:

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

winacme-ൽ ആവശ്യമായ എൻട്രി ഞങ്ങൾ സൃഷ്‌ടിച്ചതായി ഞങ്ങൾ സ്ഥിരീകരിക്കുന്നു, കൂടാതെ ഒരു സർട്ടിഫിക്കറ്റ് സൃഷ്‌ടിക്കുന്ന പ്രക്രിയ തുടരുക:

ഒരു ക്ലയന്റ് എന്ന നിലയിൽ certbot എങ്ങനെ ഉപയോഗിക്കാമെന്ന് വിവരിക്കുന്നു ഇവിടെ.

ഇത് ഒരു സർട്ടിഫിക്കറ്റ് സൃഷ്‌ടിക്കുന്ന പ്രക്രിയ പൂർത്തിയാക്കുന്നു; നിങ്ങൾക്ക് ഇത് വെബ് സെർവറിൽ ഇൻസ്റ്റാൾ ചെയ്‌ത് ഉപയോഗിക്കാം. ഒരു സർട്ടിഫിക്കറ്റ് സൃഷ്‌ടിക്കുമ്പോൾ, നിങ്ങൾ ഷെഡ്യൂളറിൽ ഒരു ടാസ്‌ക്കും സൃഷ്‌ടിക്കുന്നുവെങ്കിൽ, ഭാവിയിൽ സർട്ടിഫിക്കറ്റ് പുതുക്കൽ പ്രക്രിയ യാന്ത്രികമായി സംഭവിക്കും.

അവലംബം: www.habr.com