SSL வெளியீட்டின் தானியக்கத்தை நோக்கி

பெரும்பாலும் நாம் SSL சான்றிதழ்களுடன் வேலை செய்ய வேண்டும். ஒரு சான்றிதழை உருவாக்கி நிறுவும் செயல்முறையை நினைவில் கொள்வோம் (பெரும்பாலானவர்களுக்கு பொதுவான வழக்கில்).

  • வழங்குநரைக் கண்டுபிடி (நாங்கள் SSL ஐ வாங்கக்கூடிய ஒரு தளம்).
  • CSR உருவாக்கவும்.
  • அதை உங்கள் வழங்குநருக்கு அனுப்பவும்.
  • டொமைன் உரிமையை சரிபார்க்கவும்.
  • சான்றிதழைப் பெறுங்கள்.
  • சான்றிதழை தேவையான படிவத்திற்கு மாற்றவும் (விரும்பினால்). எடுத்துக்காட்டாக, pem இலிருந்து PKCS #12 வரை.
  • இணைய சேவையகத்தில் சான்றிதழை நிறுவவும்.

ஒப்பீட்டளவில் வேகமானது, சிக்கலானது மற்றும் புரிந்துகொள்ளக்கூடியது அல்ல. எங்களிடம் அதிகபட்சம் பத்து திட்டங்கள் இருந்தால் இந்த விருப்பம் மிகவும் பொருத்தமானது. அவற்றில் அதிகமானவை இருந்தால் என்ன செய்வது, குறைந்தது மூன்று சூழல்கள் இருந்தால் என்ன செய்வது? கிளாசிக் டெவ் - ஸ்டேஜிங் - தயாரிப்பு. இந்த வழக்கில், இந்த செயல்முறையை தானியங்குபடுத்துவது பற்றி சிந்திக்க வேண்டியது அவசியம். சிக்கலை சற்று ஆழமாக ஆராய்ந்து, சான்றிதழ்களை உருவாக்குவதற்கும் பராமரிப்பதற்கும் செலவிடும் நேரத்தை மேலும் குறைக்கும் ஒரு தீர்வைக் கண்டறிய நான் முன்மொழிகிறேன். கட்டுரையில் சிக்கலின் பகுப்பாய்வு மற்றும் மீண்டும் மீண்டும் செய்வதற்கான சிறிய வழிகாட்டி இருக்கும்.

முன்கூட்டியே முன்பதிவு செய்ய அனுமதிக்கிறேன்: எங்கள் நிறுவனத்தின் முக்கிய நிபுணத்துவம் .net மற்றும், அதன்படி, IIS மற்றும் பிற விண்டோஸ் தொடர்பான தயாரிப்புகள். எனவே, ACME கிளையண்ட் மற்றும் அதற்கான அனைத்து செயல்களும் Windows ஐப் பயன்படுத்துவதன் பார்வையில் விவரிக்கப்படும்.

யாருக்கு இது பொருத்தமானது மற்றும் சில ஆரம்ப தரவு

நிறுவனம் K ஆசிரியரால் குறிப்பிடப்படுகிறது. URL (எடுத்துக்காட்டாக): company.tld

ப்ராஜெக்ட் X என்பது எங்களின் திட்டங்களில் ஒன்றாகும், அதில் பணிபுரியும் போது, ​​சான்றிதழ்களுடன் பணிபுரியும் போது அதிகபட்ச நேர சேமிப்பை நோக்கி நாம் இன்னும் செல்ல வேண்டும் என்ற முடிவுக்கு வந்தேன். இந்த திட்டத்தில் நான்கு சூழல்கள் உள்ளன: தேவ், சோதனை, நிலை மற்றும் உற்பத்தி. தேவ் மற்றும் சோதனை எங்கள் பக்கத்தில் உள்ளன, ஸ்டேஜிங் மற்றும் உற்பத்தி வாடிக்கையாளர் பக்கத்தில் உள்ளன.

திட்டத்தின் ஒரு சிறப்பு அம்சம் என்னவென்றால், இது துணை டொமைன்களாகக் கிடைக்கும் தொகுதிகள் அதிக அளவில் உள்ளது.

அதாவது, எங்களிடம் பின்வரும் படம் உள்ளது:

தேவ்
சோதனை
நோயின்
உற்பத்தி

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 சான்றிதழ்களின் அதிகபட்ச செல்லுபடியாகும் காலத்தை குறைக்க கூகுள் முன்மொழிந்தது. அனைத்து விளைவுகளுடன்.
  • திட்டங்கள் மற்றும் ஒட்டுமொத்த நிறுவனத்தின் உள் தேவைகளுக்காக SSL ஐ வழங்குதல் மற்றும் பராமரிக்கும் செயல்முறையை எளிதாக்குதல்.
  • சான்றிதழ் பதிவுகளின் மையப்படுத்தப்பட்ட சேமிப்பகம், இது DNS ஐப் பயன்படுத்தி டொமைன் சரிபார்ப்பின் சிக்கலை ஓரளவு தீர்க்கிறது மற்றும் அதைத் தொடர்ந்து தானியங்கி புதுப்பித்தல், மேலும் வாடிக்கையாளர் நம்பிக்கையின் சிக்கலையும் தீர்க்கிறது. இருப்பினும், பங்குதாரர்/செயல்திறன் நிறுவனத்தின் சேவையகத்தில் உள்ள CNAME மூன்றாம் தரப்பு ஆதாரத்தை விட நம்பகமானது.
  • சரி, இறுதியாக, இந்த விஷயத்தில் "இல்லாததை விட வைத்திருப்பது நல்லது" என்ற சொற்றொடர் சரியாக பொருந்துகிறது.

ஒரு SSL வழங்குநரைத் தேர்ந்தெடுப்பது மற்றும் தயாரிப்பு படிகள்

இலவச SSL சான்றிதழ்களுக்கான கிடைக்கக்கூடிய விருப்பங்களில், cloudflare மற்றும் letsencrypt ஆகியவை கருதப்பட்டன. இதற்கான டிஎன்எஸ் (மற்றும் வேறு சில திட்டப்பணிகள்) கிளவுட்ஃப்ளேர் மூலம் வழங்கப்படுகிறது, ஆனால் நான் அவர்களின் சான்றிதழ்களைப் பயன்படுத்துவதில் ரசிகன் அல்ல. எனவே, letsencrypt ஐப் பயன்படுத்த முடிவு செய்யப்பட்டது.
வைல்டு கார்டு SSL சான்றிதழை உருவாக்க, நீங்கள் டொமைன் உரிமையை உறுதிப்படுத்த வேண்டும். இந்த நடைமுறையானது சில DNS பதிவை (TXT அல்லது CNAME) உருவாக்கி, சான்றிதழை வழங்கும்போது அதைச் சரிபார்ப்பதை உள்ளடக்குகிறது. லினக்ஸில் ஒரு பயன்பாடு உள்ளது - certbot, இது உங்களை ஓரளவு (அல்லது சில DNS வழங்குநர்களுக்கு) இந்த செயல்முறையை தானியக்கமாக்க அனுமதிக்கிறது. விண்டோஸுக்கு கண்டுபிடிக்கப்பட்டு சரிபார்க்கப்பட்டது ACME கிளையன்ட் விருப்பங்களை நான் செட்டில் செய்தேன் WinACME.

டொமைனுக்கான பதிவு உருவாக்கப்பட்டது, சான்றிதழை உருவாக்குவதற்கு செல்லலாம்:

SSL வெளியீட்டின் தானியக்கத்தை நோக்கி

வைல்டு கார்டு சான்றிதழை வழங்குவதற்கான டொமைன் உரிமையை உறுதிப்படுத்துவதற்கான கிடைக்கக்கூடிய விருப்பங்கள், கடைசி முடிவில் நாங்கள் ஆர்வமாக உள்ளோம்:

  1. DNS பதிவுகளை கைமுறையாக உருவாக்கவும் (தானியங்கி புதுப்பிப்பு ஆதரிக்கப்படவில்லை)
  2. acme-dns சேவையகத்தைப் பயன்படுத்தி DNS பதிவுகளை உருவாக்குதல் (நீங்கள் இதைப் பற்றி மேலும் படிக்கலாம் இங்கே.
  3. உங்கள் சொந்த ஸ்கிரிப்டைப் பயன்படுத்தி DNS பதிவுகளை உருவாக்குதல் (certbotக்கான cloudflare செருகுநிரலைப் போன்றது).

முதல் பார்வையில், மூன்றாவது புள்ளி மிகவும் பொருத்தமானது, ஆனால் 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.

SSL வெளியீட்டின் தானியக்கத்தை நோக்கி

தேவையான பதிவை நாங்கள் உருவாக்கி, அது சரியாக உருவாக்கப்பட்டது என்பதை உறுதிசெய்கிறோம்:

SSL வெளியீட்டின் தானியக்கத்தை நோக்கி

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

Winacme இல் தேவையான உள்ளீட்டை உருவாக்கியுள்ளோம் என்பதை உறுதிசெய்து, சான்றிதழை உருவாக்கும் செயல்முறையைத் தொடரவும்:

SSL வெளியீட்டின் தானியக்கத்தை நோக்கி

ஒரு கிளையண்டாக சர்ட்போட்டை எவ்வாறு பயன்படுத்துவது என்பது விவரிக்கப்பட்டுள்ளது இங்கே.

இது ஒரு சான்றிதழை உருவாக்கும் செயல்முறையை நிறைவு செய்கிறது; நீங்கள் அதை இணைய சேவையகத்தில் நிறுவி அதைப் பயன்படுத்தலாம். ஒரு சான்றிதழை உருவாக்கும் போது, ​​நீங்கள் திட்டமிடலிலும் ஒரு பணியை உருவாக்கினால், எதிர்காலத்தில் சான்றிதழ் புதுப்பித்தல் செயல்முறை தானாகவே நிகழும்.

ஆதாரம்: www.habr.com

கருத்தைச் சேர்