სერტიფიკატი არის ფაილი, რომელიც ამბობს: "ეს საჯარო გასაღები ეკუთვნის იმას, ვინც example.com-ს აკონტროლებს", და ხელმოწერილია ორგანოს მიერ, რომელსაც ბრაუზერები უკვე ენდობიან. Let's Encrypt მათ უფასოდ იძლევა, რადგან საინტერესო ნაწილი ფაილი არ არის, არამედ დადასტურება: ავტომატური გაცვლა სახელად ACME, რომელშიც სერტიფიცირების ორგანო გაძლევს პატარა დავალებას, რომელსაც მხოლოდ სახელის ნამდვილი მფლობელი შეძლებდა. შეასრულე და მიიღებ სერტიფიკატს, რომელიც 90 დღე გრძელდება. გახადე მისი გავლა ავტომატური და სერტიფიკატებზე აღარასოდეს იფიქრებ.
ეს არის, რა ხდება ამ გაცვლისას, რა არღვევს მას და რა უნდა გააკეთო შენ თავად მას შემდეგაც, რაც lock-ის ხატულა გამოჩნდება.
რას ამტკიცებს სერტიფიკატი სინამდვილეში#
ნაკლებს, ვიდრე უმეტესობა ფიქრობს. გავრცელებული Let's Encrypt სერტიფიკატი domain validated არის: ერთადერთი, რასაც ის აცხადებს, ისაა, რომ ვინც მოითხოვა, იმ მომენტში შეძლო დომენის სახელზე კონტროლის დემონსტრირება. ის არაფერს ამბობს იმაზე, ვინ ატარებს საიტს, არსებობს თუ არა კომპანია, ან არის თუ არა საიტი პატიოსანი. phishing საიტს შეუძლია და იღებს კიდეც ვალიდურ სერტიფიკატს ოცდაათ წამში.
რასაც ის გაძლევს, ღირს ქონად:
- დაშიფვრა. ვიზიტორსა და სერვერს შორის არავის შეუძლია ტრაფიკის წაკითხვა ან შეცვლა. საჯარო wifi ქსელზე ეს არის განსხვავება კერძო და საჯარო სესიას შორის.
- მთლიანობა. შუამავალი ვერ შეიტანს გვერდზე სკრიპტს, გადამისამართებას ან რეკლამას.
- იდენტობა სახელისთვის. ვიზიტორი ლაპარაკობს მანქანასთან, რომელზეც DNS მიუთითებს და არა იმასთან, ვინც პირველმა უპასუხა.
Organisation-validated და extended-validation სერტიფიკატები არსებობს, ფული ღირს და მათში ადამიანი კომპანიის ჩანაწერებს ამოწმებს. ისინი ღირს ყიდვად, თუ ხელშეკრულება მოითხოვს. ბრაუზერებმა 2019 წელს შეწყვიტეს მისამართის ზოლში კომპანიის სახელის ჩვენება, ამიტომ ხილული სარგებელი ახლა ნულია.
ACME გაცვლა ნაბიჯ-ნაბიჯ#
ACME არის პროტოკოლი - RFC 8555 - შენს მხარეს მყოფ კლიენტსა და CA-ს შორის. Certbot ერთი კლიენტია, შენი hosting panel მეორეს უშვებს, და ნაბიჯები იდენტურია, რომელიც არ უნდა იყოს.
- ანგარიში. კლიენტი აგენერირებს გასაღებების წყვილს და რეგისტრირებს მას CA-ში. ეს ერთხელ ხდება და მას შემდეგ გაიდენტიფიცირებს.
- შეკვეთა. კლიენტი ითხოვს სერტიფიკატს ერთი ან მეტი სახელისთვის:
example.com,www.example.com. - ავტორიზაცია და challenge. ყოველი სახელისთვის CA პასუხობს token-ით და კონტროლის დადასტურების გზების სიით.
- მომზადება. კლიენტი აქვეყნებს პასუხს - ფაილს შენს ვებ სერვერზე, ან DNS ჩანაწერს.
- ვალიდაცია. კლიენტი CA-ს ეუბნება, რომ მზადაა. CA სახელს საკუთარი მხრიდან წყვეტს, პასუხს იღებს და ამოწმებს. სწორედ ეს ნაბიჯია, რომელიც ვარდება, და ვარდება იმიტომ, რომ CA სხვას ხედავს, ვიდრე შენ.
- დასრულება. კლიენტი აგზავნის სერტიფიკატის ხელმოწერის მოთხოვნას საჯარო გასაღებით, რომელსაც გამოიყენებს. CA ხელს აწერს.
- ჩამოტვირთვა. კლიენტი იღებს სერტიფიკატსა და შუალედურ ჯაჭვს, აყენებს და ვებ სერვერს ხელახლა ტვირთავს.
ამ სურათში მთავარია, რომ CA ამოწმებს საჯარო ინტერნეტიდან, საჯარო DNS-ით. შენი /etc/hosts ფაილი, შენი VPN, შენი ბრაუზერის ქეში და DNS, რომელსაც შენი ლეპტოპი შემთხვევით იყენებს, ყველა უმნიშვნელოა. თუ სახელი დანარჩენი მსოფლიოსთვის ძველ host-ზე წყდება, გაცემა ვარდება, რაც არ უნდა სწორი იყოს ახალი სერვერი.
სამი challenge ტიპი#
| Challenge | რა სჭირდება | Wildcards | ტიპური გამოყენება |
|---|---|---|---|
http-01 | Port 80 ხელმისაწვდომია, ფაილი /.well-known/acme-challenge/-ში | არა | თითქმის ყველა ჩვეულებრივი საიტი |
dns-01 | TXT ჩანაწერი _acme-challenge.<name>-ზე | დიახ | Wildcard-ები, სერვერები საჯარო port 80-ის გარეშე |
tls-alpn-01 | Port 443 და TLS listener-ის კონტროლი | არა | Proxy-ები და load balancer-ები, რომლებიც 443-ს ფლობენ |
HTTP-01 ნაგულისხმევია. კლიენტი წერს ფაილს, რომლის სახელი token-ია და რომლის შიგთავსი token-ია პლუს შენი ანგარიშის გასაღების hash, ხოლო CA იღებს http://example.com/.well-known/acme-challenge/<token>-ს უბრალო HTTP-ით port 80-ზე. ის გადამისამართებებს მიჰყვება, ამიტომ საიტი, რომელიც ყველაფერს HTTPS-ზე აგზავნის, ჩვეულებრივ კარგადაა, მაგრამ წესი, რომელიც ამ path-ზე აბრუნებს 404-ს, login გვერდს ან WAF-ის ბლოკს, არა.
DNS-01 ერთადერთი გზაა wildcard-ის მისაღებად, როგორიცაა *.example.com, და ერთადერთი ვარიანტი, როცა port 80 დახურულია ან მანქანა საჯაროდ საერთოდ მიუწვდომელია. ფასი ისაა, რომ მისი ავტომატიზაცია შენი DNS პროვაიდერის API token-ს მოითხოვს, ხოლო DNS propagation ყოველ განახლებას ანელებს. გაითვალისწინე, რომ wildcard ერთ დონეს ფარავს: *.example.com ემთხვევა app.example.com-ს, მაგრამ არა a.b.example.com-ს.
TLS-ALPN-01 port 443-ზე კონტროლს ამტკიცებს სპეციალურ handshake-ზე პასუხით acme-tls/1 პროტოკოლის გამოყენებით. მას მხოლოდ მაშინ შეხვდები, თუ proxy გაუშვი, რომელიც TLS-ს თავად ამუშავებს.
უმეტესობა არასოდეს არჩევს. კლიენტი ირჩევს HTTP-01-ს, ის მუშაობს, და არჩევანი საინტერესო მხოლოდ მაშინ ხდება, როცა wildcard გინდა.
განახლება და ფანჯარა, რომელსაც მნიშვნელობა აქვს#
Let's Encrypt-ის სერტიფიკატები 90 დღე გრძელდება. ეს შეგნებულია: მოკლე სიცოცხლე ავტომატიზაციას აიძულებს, ავტომატიზაცია კი აჩერებს ყოველწლიურ ავარიას, როცა ვიღაცას დაავიწყდა. განახლება განსაკუთრებული ოპერაცია არ არის - ეს იგივე გაცვლაა ხელახლა, შეკვეთიდან ჩამოტვირთვამდე.
კლიენტები ადრე ანახლებენ, რომ მარცხისთვის სივრცე დარჩეს. Certbot-ის timer დღეში ორჯერ მუშაობს და ანახლებს ყველაფერს, რასაც 30 დღე ან ნაკლები რჩება, რაც ერთ თვეს ტოვებს ხელახალი ცდებისთვის, სანამ მომხმარებლისთვის რამე ხილული გახდება. პანელები, რომლებიც ამას შენთვის აკეთებენ, საკუთარ ფანჯარას იყენებენ: RE:NODE-ზე დაგეგმილი ამოცანა ანახლებს ნებისმიერ სერტიფიკატს, რომელიც 21-დღიან ფანჯარაში მოხვდა, ითხოვე თუ არა, ამიტომ ერთი წარუმატებელი ცდა ინციდენტი არ არის.
რასაც მაინც უნდა აკეთებდე:
- ვადის გასვლას გარედან უყურე. მარცხი, რომელიც გატკენს, არის განახლება, რომელიც კვირების განმავლობაში ჩუმად ვარდება. შეამოწმე ცოცხალი სერტიფიკატი სხვა მანქანიდან და არა დისკზე მყოფი ფაილი.
- იცოდე, რა ტვირთავს სერვერს ხელახლა. დისკზე განახლებული სერტიფიკატი არაფერს აკეთებს, სანამ ვებ სერვერი მას არ წაიკითხავს. Certbot ამას deploy hook-ით წყვეტს; პანელი შენთვის აკეთებს.
- არაფერს ნუ მიამაგრებ. HPKP მკვდარია, და სერტიფიკატის მობილურ აპში 90-დღიან სერტიფიკატზე მიმაგრება დაგეგმილი ავარიაა.
$ echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -subject -issuer -datesეს ბეჭდავს სახელს, რომელსაც სერტიფიკატი ფარავს, ვინ მოაწერა ხელი და როდის იწურება, ისე, როგორც ინტერნეტი ხედავს. ეს პირველი ბრძანებაა, რომელიც უნდა გაუშვა, როცა ვინმე სერტიფიკატის გაფრთხილებას იუწყება, რადგან ის ვადაგასულ სერტიფიკატს არასწორი სახელისგან და დაკარგული ჯაჭვისგან ასხვავებს.
ACME კლიენტის თავად გაშვება#
საკუთარ სერვერზე certbot ნაგულისხმევია და nginx plugin მთელ საქმეს აკეთებს, server block-ის რედაქტირებისა და reload-ის ჩათვლით:
$ certbot --nginx -d example.com -d www.example.com$ certbot renew --dry-runთუ გირჩევნია, რომ ის მხოლოდ ფაილებს იღებდეს და შენს კონფიგურაციას ხელს არ უხლიდეს, გამოიყენე webroot მეთოდი და მიუთითე დირექტორიაზე, საიდანაც შენი საიტი მიეწოდება:
$ certbot certonly --webroot -w /var/www/site -d example.com -d www.example.comორივე შემთხვევაში შედეგი ჩნდება /etc/letsencrypt/live/example.com/-ში:
| ფაილი | რა არის | გამოიყენე |
|---|---|---|
privkey.pem | შენი კერძო გასაღები | ssl_certificate_key-ისთვის |
fullchain.pem | Leaf პლუს შუალედური | ssl_certificate-ისთვის |
cert.pem | მხოლოდ leaf | თითქმის არასოდეს |
chain.pem | მხოლოდ შუალედური | Stapling კონფიგურაციისთვის |
გამოიყენე fullchain.pem. მხოლოდ cert.pem-ის მიწოდება კლასიკური შეცდომაა: ის შენს ბრაუზერში მუშაობს, რადგან შენმა ბრაუზერმა შუალედური სხვა საიტიდან დაიმახსოვრა, და ვარდება ვიზიტორისთვის, რომლის ბრაუზერსაც არა. ერთადერთი საიმედო შემოწმებაა მანქანიდან, რომელსაც საიტზე არასოდეს შესულა.
certbot renew --dry-run მთელ განახლებას staging გარემოს წინააღმდეგ უშვებს. გაუშვი ის სერვერის კონფიგურაციის ნებისმიერი ცვლილების შემდეგ, რადგან იმის გასაგებად, რომ განახლება გატეხილია, დრო 89 დღის შემდეგ არ არის.
მართულ ჰოსტინგზე ამისგან არაფერს აკეთებ. RE:NODE-ის აპისა და ვებ გეგმებს აქვს proxy slot: მიუთითე A ჩანაწერი ტაბზე ნაჩვენებ მისამართზე და სერტიფიკატი შენთვის გაიცემა და განახლდება. შენი აპლიკაცია სერტიფიკატს არასოდეს ხედავს, 443-ს არ უსმენს და ნამდვილ ვიზიტორის მისამართს იღებს X-Forwarded-For-ში - რას აკეთებს reverse proxy ამ მოთხოვნის გზას გადის.
Mixed content, გადამისამართებები და HSTS#
lock-ის ხატულა სამუშაოს დასასრული არ არის. სამი რამ ჩვეულებრივ რჩება.
Mixed content. გვერდი, რომელიც HTTPS-ით ჩაიტვირთა და სკრიპტს, სტილს ან iframe-ს HTTP-ით ითხოვს, ყოველ თანამედროვე ბრაუზერში ამ მოთხოვნას სრულად ბლოკავს; სურათები და მედია ჩვეულებრივ განახლდება ან იბლოკება გაფრთხილებით. გამოსავალია http:// URL-ების გენერირების შეწყვეტა. CMS-ში ეს ნიშნავს ბაზას, სადაც აბსოლუტური URL-ები წლების წინ შეინახა: გაუშვი სწორი search and replace კონტენტზე და არა გვერდების ხელით რედაქტირება, და შეამოწმე თემის შაბლონებში მყარად ჩაწერილი URL-ები. Content-Security-Policy: upgrade-insecure-requests სასარგებლო დამატებითი დაცვის header-ია, სანამ ასუფთავებ, და არა გასუფთავების შემცვლელი.
გადამისამართება. ორივე სქემის მიწოდება ნიშნავს, რომ შენი ბმულების ნახევარი არასწორია. ყველაფერი სერვერზე გააგზავნე HTTPS-ზე:
server { listen 80; server_name example.com www.example.com; return 301 https://example.com$request_uri;}ეს ასევე www-ს ერთ hop-ში apex-ში ათავსებს, რაც გინდა - www თუ apex დომენი და გადამისამართებები ფარავს, რომელ მხარეს გააკეთო და რატომ ჯდება გადამისამართებების ჯაჭვები.
HSTS. Strict-Transport-Security ბრაუზერს ეუბნება, რომ ამ სახელისთვის გარკვეული პერიოდით უარი თქვას უბრალო HTTP-ზე, რაც ხურავს შუალედს, როცა დღის პირველი მოთხოვნა დაუშიფრავად გადის.
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;დაიწყე მოკლე max-age-ით, მაგალითად 300, სანამ ამოწმებ, რომ საიტზე არაფერს სჭირდება HTTP, და შემდეგ გაზარდე. includeSubDomains ვრცელდება ყველა ქვედომენზე, დავიწყებულთა ჩათვლით, ხოლო preload სახელს ბრაუზერებში ჩაშენებულ სიაში აგზავნის, რაც ნელი და უხერხულია უკან დასაბრუნებლად. HSTS ერთადერთი header-ია აქ, რომელსაც შეუძლია საიტი ეთერიდან გააქროს, თუ შეცდები, ამიტომ ბოლოს და შეგნებულად დაამატე.
როცა გაცემა ვარდება#
თითქმის ყოველი მარცხი ერთ-ერთია ამათგან, სავარაუდოობის ამ თანმიმდევრობით.
სახელი ჯერ ამ სერვერზე არ წყდება. ჩანაწერი ხუთი წუთის წინ დაამატე და ძველი მნიშვნელობა ჯერ ქეშშია, ან ზონა პროვაიდერთან შეასწორე, რომელიც აღარ არის ავტორიტეტული. შეამოწმე შენი ქსელის გარედან dig +short example.com @1.1.1.1-ით და შეადარე მისამართს, რომელიც მოგცეს. DNS ჩანაწერები ახსნილი ფარავს, რომელი ჩანაწერი სად ეკუთვნის, ხოლო nameserver-ები თუ DNS ჩანაწერები ფარავს შემთხვევას, როცა ზონას არედაქტირებ, რომელსაც არავინ კითხულობს.
Port 80 დახურულია. HTTP-01-ს ის სჭირდება, მიუხედავად იმისა, რომ დასრულებული საიტი მხოლოდ 443-ს იყენებს. firewall წესი ან ჰოსტი, რომელიც მხოლოდ 443-ს გადაამისამართებს, ყოველ ცდას connection timeout-ით ჩააგდებს.
რაღაც challenge path-ს იჭერს. წინ მდგარი CDN, maintenance გვერდი, framework, რომელიც ყველა უცნობ path-ს 404 handler-ზე აგზავნის, ავთენტიფიკაციის ფენა მთელ საიტზე. /.well-known/acme-challenge/ ფაილს უნდა აბრუნებდეს, ავთენტიფიკაციის გარეშე.
CAA ჩანაწერი კრძალავს. CAA ჩანაწერი ჩამოთვლის, რომელ ორგანოებს შეუძლიათ შენი დომენისთვის გაცემა, და CA მას გაცემისას ამოწმებს. თუ გაქვს და ის არ ასახელებს ორგანოს, რომელსაც შენი ჰოსტი იყენებს, გაცემა CAA შეცდომით ვარდება. შეამოწმე dig CAA example.com-ით, და თუ მართულ ჰოსტინგზე ხარ, ჰკითხე მხარდაჭერას, რომელი ორგანო დაუშვა და არ გამოიცნო.
დომენი proxy-ს უკანაა, რომელიც პირველი პასუხობს. ნარინჯისფერი ღრუბლით ჩართულ CDN-თან CA CDN-ს აღწევს და არა შენ. ეს კარგია, როცა გაცემას CDN აკეთებს, და პრობლემაა, როცა შენი origin აკეთებს. Cloudflare ვებსაიტებისთვის და გეიმ სერვერებისთვის ფარავს, რომელ ფენას რომელი სერტიფიკატი უჭირავს.
rate limit-ს მიაღწიე. Let's Encrypt ზღუდავს, რამდენი სერტიფიკატი შეუძლია რეგისტრირებულ დომენს კვირაში მიიღოს და რამდენი იდენტური სერტიფიკატი შეგიძლია მოითხოვო. გამოქვეყნებული მაჩვენებლები მოიცავდა 50 სერტიფიკატს რეგისტრირებულ დომენზე კვირაში და 5 დუბლიკატს, და ისინი იცვლება, ამიტომ წაიკითხე მიმდინარე rate limit-ები, სანამ retry ციკლს დაწერ. გამოსცადე staging გარემოს წინააღმდეგ, რომელსაც გაცილებით მსუბუქი ლიმიტები აქვს და გასცემს სერტიფიკატებს, რომლებსაც ბრაუზერები არ ენდობიან.
FAQ#
უფასო სერტიფიკატი ისეთივე კარგია, როგორც ფასიანი?
დაშიფვრისთვის იდენტურია. Let's Encrypt-ის სერტიფიკატი იყენებს იმავე ალგორითმებს და მას ენდობიან იმავე ბრაუზერები, რომლებიც ფულად domain-validated სერტიფიკატს ენდობიან. შენ იხდი ორგანიზაციის ვალიდაციაში, გარანტიაში ან მხარდაჭერის ხელშეკრულებაში - და არა უფრო ძლიერ დაშიფვრაში.
რატომ 90 დღე და არა ერთი წელი?
მოკლე სიცოცხლე ზღუდავს მოპარული გასაღების ზიანს და აიძულებს განახლების ავტომატიზაციას. ინდუსტრია იმავე მიმართულებით მოძრაობს ფასიანი სერტიფიკატებისთვისაც: მაქსიმალური ვადები არაერთხელ შემცირდა, და ყველაფერი, რაც იმაზეა დამოკიდებული, რომ ადამიანს ახსოვდეს, საბოლოოდ ის იქნება, რაც გატყდება.
მჭირდება თუ არა სერტიფიკატი საიტისთვის ავტორიზაციის გარეშე?
დიახ. ბრაუზერები უბრალო HTTP-ს არასაიმედოდ აღნიშნავს, საძიებო სისტემები HTTPS-ს ანიჭებენ უპირატესობას, და თანამედროვე ბრაუზერის ფუნქციები geolocation-იდან service worker-ებამდე მის გარეშე მუშაობაზე უარს ამბობს. ასევე არ არსებობს გვერდი, რომელიც იმდენად მოსაწყენია, რომ გზაში არ შეიცვალოს.
რა ხდება, როცა სერტიფიკატს ვადა გაუვა?
ვიზიტორები იღებენ მთელ გვერდზე გაფრთხილებას, რომელიც უნდა გადაკლიკონ, და ყველაფერი ავტომატიზებული - API კლიენტი, webhook გამგზავნი, მობილური აპი - უბრალოდ ვარდება. საშეღავათო პერიოდი არ არსებობს. სწორედ ამიტომ იზომება განახლების ფანჯრები კვირებით და არა დღეებით.
შეუძლია თუ არა ერთ სერტიფიკატს რამდენიმე დომენის დაფარვა?
დიახ. სერტიფიკატს შეუძლია ჩამოთვალოს რამდენიმე სახელი თავის subject alternative name ველში, ამიტომ example.com, www.example.com და shop.example.net ერთს გაუყოფენ. wildcard ფარავს ერთი სახელის ყველა პირდაპირ ქვედომენს, მაგრამ DNS challenge სჭირდება.
რატომ წერს ჩემი საიტი "not secure", როცა სერტიფიკატი ვალიდურია?
Mixed content, თითქმის ყოველთვის. სერტიფიკატი კარგადაა და გვერდი რაღაცას უბრალო HTTP-ით ტვირთავს. გახსენი ბრაუზერის console: ის ასახელებს ზუსტ URL-ს, რომელიც იბლოკება.
კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.