🥇SSL जारी करण्याच्या ऑटोमेशनच्या दिशेने

बर्‍याचदा आम्हाला SSL प्रमाणपत्रांसह काम करावे लागते. प्रमाणपत्र तयार करण्याची आणि स्थापित करण्याची प्रक्रिया लक्षात ठेवूया (सर्वसाधारण बाबतीत बहुतेकांसाठी).

एक प्रदाता शोधा (एक साइट जिथे आम्ही SSL खरेदी करू शकतो).
CSR व्युत्पन्न करा.
ते तुमच्या प्रदात्याला पाठवा.
डोमेन मालकी सत्यापित करा.
प्रमाणपत्र मिळवा.
प्रमाणपत्राला आवश्यक फॉर्ममध्ये रूपांतरित करा (पर्यायी). उदाहरणार्थ, pem पासून PKCS #12 पर्यंत.
वेब सर्व्हरवर प्रमाणपत्र स्थापित करा.

तुलनेने वेगवान, क्लिष्ट आणि समजण्यासारखे नाही. आमच्याकडे जास्तीत जास्त दहा प्रकल्प असल्यास हा पर्याय योग्य आहे. जर त्यापैकी अधिक असतील आणि त्यांच्याकडे किमान तीन वातावरण असतील तर? क्लासिक देव - स्टेजिंग - उत्पादन. या प्रकरणात, ही प्रक्रिया स्वयंचलित करण्याबद्दल विचार करणे योग्य आहे. मी समस्येमध्ये थोडे खोलवर जाण्याचा आणि एक उपाय शोधण्याचा प्रस्ताव देतो ज्यामुळे प्रमाणपत्रे तयार करण्यात आणि त्यांची देखभाल करण्यासाठी लागणारा वेळ कमी होईल. लेखात समस्येचे विश्लेषण आणि पुनरावृत्तीसाठी एक लहान मार्गदर्शक असेल.

मला आगाऊ आरक्षण करू द्या: आमच्या कंपनीचे मुख्य स्पेशलायझेशन म्हणजे .net, आणि त्यानुसार, IIS आणि इतर विंडोज संबंधित उत्पादने. म्हणून, ACME क्लायंट आणि त्यासाठीच्या सर्व क्रियांचे वर्णन Windows वापरण्याच्या दृष्टिकोनातून देखील केले जाईल.

कोणासाठी हे संबंधित आहे आणि काही प्रारंभिक डेटा

कंपनी के लेखकाने प्रतिनिधित्व केले. 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 साठी नाही. पण तरीही मला वेगळे विकत घ्यायचे नाही.

आणि हे केवळ एका कंपनीच्या एका प्रकल्पाच्या उदाहरणावर आधारित आहे. आणि, अर्थातच, एकापेक्षा जास्त प्रकल्प आहेत.

प्रत्येकाने या समस्येचे निराकरण करण्याची सामान्य कारणे यासारखी दिसतात:

अलीकडे Google ने SSL प्रमाणपत्रांचा कमाल वैधता कालावधी कमी करण्याचा प्रस्ताव दिला आहे. सर्व परिणामांसह.
प्रकल्प आणि संपूर्ण कंपनीच्या अंतर्गत गरजांसाठी SSL जारी करण्याची आणि देखरेख करण्याची प्रक्रिया सुलभ करा.
प्रमाणपत्र रेकॉर्डचे केंद्रीकृत संचयन, जे DNS आणि त्यानंतरच्या स्वयंचलित नूतनीकरणाचा वापर करून डोमेन पडताळणीच्या समस्येचे अंशतः निराकरण करते आणि क्लायंटच्या विश्वासाची समस्या देखील सोडवते. तरीही, भागीदार/परफॉर्मर कंपनीच्या सर्व्हरवरील CNAME तृतीय-पक्ष संसाधनापेक्षा अधिक विश्वासार्ह आहे.
बरं, शेवटी, या प्रकरणात "नसण्यापेक्षा असणे चांगले आहे" हे वाक्य उत्तम प्रकारे बसते.

SSL प्रदाता निवडणे आणि तयारीचे चरण

विनामूल्य SSL प्रमाणपत्रांसाठी उपलब्ध पर्यायांपैकी, क्लाउडफ्लेअर आणि लेटसेनक्रिप्टचा विचार केला गेला. यासाठी (आणि काही इतर प्रकल्प) DNS क्लाउडफ्लेअरद्वारे होस्ट केले आहे, परंतु मी त्यांची प्रमाणपत्रे वापरण्याचा चाहता नाही. त्यामुळे letsencrypt वापरण्याचा निर्णय घेण्यात आला.
वाइल्डकार्ड SSL प्रमाणपत्र तयार करण्यासाठी, तुम्हाला डोमेन मालकीची पुष्टी करणे आवश्यक आहे. या प्रक्रियेमध्ये काही DNS रेकॉर्ड (TXT किंवा CNAME) तयार करणे आणि नंतर प्रमाणपत्र जारी करताना त्याची पडताळणी करणे समाविष्ट आहे. लिनक्समध्ये एक उपयुक्तता आहे - सर्टबॉट, जे तुम्हाला ही प्रक्रिया अंशतः (किंवा पूर्णपणे काही DNS प्रदात्यांसाठी) स्वयंचलित करण्याची परवानगी देते. पासून Windows साठी आढळले आणि सत्यापित केले ACME क्लायंट पर्याय ज्यावर मी सेटल झालो WinACME.

आणि डोमेनसाठी रेकॉर्ड तयार केले गेले आहे, चला प्रमाणपत्र तयार करण्यासाठी पुढे जाऊया:

आम्हाला शेवटच्या निष्कर्षामध्ये स्वारस्य आहे, म्हणजे, वाइल्डकार्ड प्रमाणपत्र जारी करण्यासाठी डोमेन मालकीची पुष्टी करण्यासाठी उपलब्ध पर्याय:

DNS रेकॉर्ड स्वहस्ते तयार करा (स्वयंचलित अद्यतन समर्थित नाही)
acme-dns सर्व्हर वापरून DNS रेकॉर्ड तयार करणे (आपण याबद्दल अधिक वाचू शकता येथे.
तुमची स्वतःची स्क्रिप्ट वापरून DNS रेकॉर्ड तयार करणे (सर्टबॉटसाठी क्लाउडफ्लेअर प्लगइन प्रमाणे).

पहिल्या दृष्टीक्षेपात, तिसरा मुद्दा अगदी योग्य आहे, परंतु 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 त्याचे निराकरण होणार नाही, कारण ते सेवा देणारा DNS सर्व्हर अद्याप चालू नाही.

रेकॉर्ड तयार केले गेले आहेत, आम्ही ACME-DNS सर्व्हर सेट अप आणि लॉन्च करण्यासाठी पुढे जाऊ. ते माझ्या उबंटू सर्व्हरवर लाइव्ह होईल डॉकर कंटेनर, परंतु गोलंग उपलब्ध असेल तेथे तुम्ही ते कुठेही चालवू शकता. विंडोज देखील योग्य आहे, परंतु तरीही मी लिनक्स सर्व्हरला प्राधान्य देतो.

आवश्यक निर्देशिका आणि फाइल्स तयार करा:

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

चला तुमच्या आवडत्या टेक्स्ट एडिटरसह vim वापरू आणि नमुना 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 चालवा. आम्हाला निवडणुकीत स्वारस्य आहे:

M: नवीन प्रमाणपत्र तयार करा (संपूर्ण पर्याय)
2:मॅन्युअल इनपुट
2: [dns-01] acme-dns सह पडताळणी रेकॉर्ड तयार करा (https://github.com/joohoi/acme-dns)
ACME-DNS सर्व्हरच्या लिंकबद्दल विचारले असता, उत्तरामध्ये तयार केलेल्या सर्व्हरची URL (https) एंटर करा. 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

SSL जारी करण्याच्या ऑटोमेशनच्या दिशेने

कोणासाठी हे संबंधित आहे आणि काही प्रारंभिक डेटा

SSL प्रदाता निवडणे आणि तयारीचे चरण

ACME-DNS सर्व्हर आणि प्रमाणपत्र जारी करण्याची प्रक्रिया सेट करणे

एक टिप्पणी जोडा Отменить ответ