მიუთითე დომენი შენს სერვერზე და მიიღე SSL სერტიფიკატი

სამი ნაბიჯია, და მათგან მხოლოდ ერთია საინტერესო. დაამატე hostname შენი სერვერის proxy სლოტში, შექმენი A ჩანაწერი შენს DNS პროვაიდერთან იმ მისამართზე, რომელსაც სლოტი აჩვენებს, და დაელოდე, სანამ სახელი გადაწყდება. სერტიფიკატი ავტომატურად გაიცემა, როგორც კი ეს მოხდება, და ავტომატურად განახლდება თავისი სიცოცხლის ბოლო 21 დღეში, ამიტომ წლიურად არაფერი გაქვს გასაკეთებელი.

საინტერესო ნაბიჯი ლოდინია, რადგან ყველა ჩავარდნა სწორედ იქ ცხოვრობს. სერტიფიკატის გაცემა ამოწმებს, რომ სახელი ნამდვილად იმ სერვერზე მიუთითებს, რომელიც მას ითხოვს, რაც ნიშნავს, რომ სერტიფიკატს ვერ მიიღებ სახელზე, რომელიც ისევ შენს ძველ ჰოსტზე იხსნება, რეგისტრატორთან პარკირებულია, აქვს CAA ჩანაწერი, რომელიც სხვა ორგანოს ასახელებს, ან დამალულია CDN-ის უკან, რომლის origin მიუწვდომელია. ეს პოსტი გვიჩვენებს, რას აკეთებს თითოეული ჩანაწერი, როგორ შეამოწმო, რას ხედავს დანარჩენი მსოფლიო და არა ის, რაც შენს მანქანას აქვს ქეშირებული, და ექვს რამეს, რომელიც სერტიფიკატის გაცემას აჩერებს.

რას აკეთებს proxy სლოტი#

აპლიკაციისა და ვებ გეგმები შეიცავს reverse-proxy სლოტს. სწორედ ეს სლოტი აქცევს https://app.example.com-ს კავშირად შენს კონტეინერთან: ის იღებს მოთხოვნას საჯარო მისამართზე, იქვე ასრულებს TLS-ს და ამარტივებს მოთხოვნას ჩვეულებრივ HTTP-ად ერთ პორტზე, რომელსაც შენი აპლიკაცია უსმენს.

ამ ფორმის ორი შედეგი პოსტის დანარჩენი ნაწილისთვის მნიშვნელოვანია.

შენი აპლიკაცია TLS-ს არასოდეს ხედავს. ის იღებს ჩვეულებრივ HTTP-ს საკუთარ პორტზე. ამიტომ აპი, რომელიც ყველა არა-HTTPS მოთხოვნას HTTPS-ზე გადაამისამართებს, proxy-ის უკან უსასრულო ციკლში ვარდება, და ამიტომ მოდის კლიენტის რეალური მისამართი X-Forwarded-For header-ში და არა თვით კავშირში. რას აკეთებს reverse proxy ზოგად შემთხვევას ფარავს.

ეს HTTP-ა და არა ყველაფერი. proxy სლოტი ვებ ტრაფიკს ამუშავებს. გეიმ სერვერს ამ გზით ვერ მიაღწევ: Minecraft ან Valheim სერვერს სახელი პირდაპირ სერვერის მისამართზე უნდა მიუთითო A ჩანაწერით, და მოთამაშეები უერთდებიან პირდაპირ თამაშის პორტს. დომენის მიბმა გეიმ სერვერზე ამას ფარავს, ხოლო SRV ჩანაწერები Minecraft-ისთვის - არასტანდარტული პორტის მოთამაშეებისგან დამალვას.

აქ DNS-ს არ ვუშვებთ და დომენებს არ ვყიდით, ამიტომ ქვემოთ მოცემული ჩანაწერები იქმნება იქ, სადაც შენი დომენის DNS ცხოვრობს - რეგისტრატორთან, რომლისგანაც იყიდე, ან DNS პროვაიდერთან, რომელზეც გადაიტანე. თუ დარწმუნებული არ ხარ, რომელია შენი დომენისთვის ავტორიტეტული, nameserver-ები თუ DNS ჩანაწერები განსხვავებაა, რომელიც ჯერ უნდა წაიკითხო, რადგან ჩანაწერების არასწორ მართვის პანელში რედაქტირება ნაშუადღევის გასატარებლად ნამდვილად გავრცელებული გზაა.

ჩანაწერები, რომლებიც გჭირდება#

ქვედომენისთვის ერთი ჩანაწერი. მთელი დომენისთვის, ჩვეულებრივ, ორი.

წერტილები, რომლებზეც ხალხი ებმევა:

Apex CNAME ვერ იქნება. DNS სპეციფიკაცია არ უშვებს CNAME-ს ერთად სხვა ჩანაწერებთან, რომლებიც დომენის apex-ს უნდა ჰქონდეს. ბევრი პროვაიდერი გვთავაზობს ALIAS-ს, ANAME-ს ან CNAME flattening-ს ამის გვერდის ავლისთვის, რაც კარგია; თუ შენსას არა აქვს, გამოიყენე A ჩანაწერი apex-ზე და CNAME www-ზე.

აირჩიე ერთი კანონიკური ჰოსტი. სერვისი მიაწოდე ან example.com-ზე, ან www.example.com-ზე და მეორე გადაამისამართე მასზე. ორივეს დამოუკიდებლად მუშაობა შენს საძიებო შედეგებსა და cookie-ებს ორად ჰყოფს. www თუ apex დომენი და გადამისამართებები ლოგიკასა და გადამისამართების წესებს შეიცავს.

დაამატე ორივე სახელი proxy სლოტში, თუ ორივე უნდა მუშაობდეს. სერტიფიკატი ფარავს სახელებს, რომელთათვისაც გაიცა, და მოთხოვნა www.example.com-ზე, რომელიც სლოტს მიაღწევს, რომელმაც მხოლოდ example.com იცის, ჩავარდება ნებისმიერი გადამისამართების დახმარებამდე.

ნუ გამოაქვეყნებ AAAA ჩანაწერს, რომელსაც ვერ ემსახურები. თუ შენს სერვერს IPv6 მისამართი არ აქვს, წინა ჰოსტიდან დარჩენილი AAAA ჩანაწერი უსარგებლოზე უარესია: ბრაუზერები და სერტიფიცირების ორგანო მას პირველად სცდიან და ვარდებიან. წაშალე. IPv6 და გეიმ სერვერები ფარავს, როდის გინდა ის ნამდვილად.

ქვედომენი თითო სერვისზე იაფია. app.example.com, api.example.com, status.example.com თითოეული ერთ ჩანაწერს ჯდება და სერტიფიკატებსა და მარშრუტიზაციას ცალკე ინახავს. იხილე ქვედომენები სერვერებისთვის.

შეამცირე TTL, სანამ რამეს გადაიტან#

ყოველ DNS ჩანაწერს აქვს TTL - წამების რაოდენობა, რომლის განმავლობაშიც resolver-ს პასუხის ქეშირება შეუძლია. ნაგულისხმევი უმეტეს პროვაიდერთან 3600 ან 14400-ია, რაც ნიშნავს ერთიდან ოთხ საათამდე, როცა ზოგი resolver ძველ მისამართს გასცემს მას შემდეგაც, რაც შეცვალე.

გამოსავალი ერთი ნაბიჯით წინ დაგეგმვაა. სულ მცირე ერთი დღით ადრე, სანამ ჩანაწერის შეცვლას აპირებ, დააყენე მისი TTL 300-ზე. ყველა resolver, რომელიც ამასობაში განახლდება, მოკლე მნიშვნელობას აიღებს, და როცა ნამდვილ ცვლილებას შეიტან, მსოფლიო ოთხი საათის ნაცვლად ხუთ წუთში მიჰყვება. დააბრუნე 3600-ზე გადატანიდან ერთი დღის შემდეგ.

ეს არის განსხვავება გადართვას შორის, რომელიც წუთებს იღებს, და გადართვას შორის, როცა შენი ვიზიტორების მესამედი დანარჩენ ნაშუადღევს ძველ საიტს ხედავს. ეს ასევე ამ პოსტის ყველაზე სასარგებლო ერთი რამაა, თუ ცოცხალ საიტს გადააქვს, და წინასწარ უნდა გაკეთდეს - TTL-ის შემცირება ცვლილების მომენტში არაფერს იძლევა, რადგან ის, რაც უკვე ქეშშია, ძველი TTL-ია.

იმის შემოწმება, რასაც მსოფლიო ხედავს#

შენი საკუთარი მანქანა ამის შესამოწმებლად ყველაზე ცუდი ადგილია. მას აქვს resolver-ის ქეში, შესაძლოა ბრაუზერის ქეში მის თავზე და ზოგჯერ hosts ფაილის ჩანაწერი, რომელიც ექვსი თვის წინ დაამატე. ამის ნაცვლად პირდაპირ საჯარო resolver-ს ჰკითხე.

# What the record is, from a resolver that is not yours$ dig +short app.example.com A @1.1.1.1203.0.113.10# Follow the delegation from the root, which shows the authoritative answer$ dig +trace app.example.com# Is anything restricting which authority may issue certificates?$ dig +short example.com CAA0 issue "letsencrypt.org"

Windows-ზე dig-ის გარეშე პირველს nslookup app.example.com 1.1.1.1 აკეთებს. ონლაინ "DNS checker" საიტები, რომლებიც მსოფლიოს ირგვლივ ოც resolver-ს ეკითხებიან, სასარგებლოა იმის დასადასტურებლად, რომ ცვლილება გავრცელდა, და უსარგებლო ყველაფრისთვის დანარჩენისთვის.

რას უნდა დააკვირდე:

• პასუხი ზუსტად ემთხვევა proxy სლოტზე ნაჩვენებ მისამართს.
• მის გვერდით მოძველებული AAAA ჩანაწერი არ არის.
• არ არის CNAME, რომელიც შენს ძველ ჰოსტზე მიუთითებს და დაგავიწყდა.
• TTL სრულ dig გამოტანაში, რომელიც გეუბნება, რამდენი დრო რჩება მიმდინარე ქეშირებულ პასუხს.

თუ dig +trace განსხვავებულ პასუხს იძლევა, ვიდრე dig @1.1.1.1, ცვლილება ავტორიტეტულია და უბრალოდ ჯერ არ ძველდება საჯარო resolver-ში. ეს ნორმალურია და ლოდინის საკითხია.

როგორ გაიცემა სერტიფიკატი#

სერტიფიკატებს გასცემს ორგანო, რომელიც ჯერ ამოწმებს, რომ სახელს აკონტროლებ. ასეთი ჰოსტისთვის გავრცელებული მეთოდია HTTP ვალიდაცია: ორგანო ითხოვს კონკრეტულ ფაილს /.well-known/acme-challenge/-ის ქვეშ პორტ 80-ზე ამ hostname-ისთვის, და proxy პასუხობს. თუ პასუხი სწორად დაბრუნდა, სერტიფიკატი გაიცემა, ჩვეულებრივ წამებში.

ეს ერთი წინადადება თითქმის ყველაფერს განმარტავს ჩავარდნების შესახებ. შემოწმება ხდება საჯარო ინტერნეტით, საჯარო DNS-ის გამოყენებით, პორტ 80-ზე. ამიტომ სახელი აქ უნდა გადაწყდეს, პორტ 80-მა proxy-ს უნდა მიაღწიოს და არცერთმა გადამისამართებამ ორგანო ისეთ ადგილას არ უნდა გაგზავნოს, რომელსაც პასუხის გაცემა არ შეუძლია. თვით გადამისამართებებს მიჰყვებიან, ამიტომ არსებული HTTP-დან HTTPS-ზე წესი ავტომატურად პრობლემა არ არის - მოთხოვნა უბრალოდ ამავე სერვერს უნდა დაუბრუნდეს.

განახლება ავტომატურად მუშაობს სერტიფიკატის მოქმედების ბოლო 21 დღეში, რაც რამდენიმე კვირის განმეორებით ცდას გაძლევს, სანამ რამე ამოიწურება. პრაქტიკული ეფექტია, რომ დომენი, რომელიც აქ აღარ იხსნება, არ ჩავარდება დარღვევის დღეს; ის ჩავარდება სამი კვირის შემდეგ, როცა განახლებას დრო ამოეწურა, და ეს გამაოგნებელი სიმპტომია, თუ არ იცი, რომ ეძებო.

ორი ლიმიტი, რომლის ცოდნაც ღირს, სანამ ციკლში განმეორებით ცდას დაიწყებ. სერტიფიცირების ორგანოები გაცემას ზღუდავენ დომენზე და ერთი და იმავე სახელების ნაკრებზე, ხოლო განმეორებით ჩავარდნილი ვალიდაცია ცალკე ლიმიტში ითვლება - ასე რომ საათში ოცმა ცდამ შეიძლება უფრო დიდი ხნით დაგბლოკოს, ვიდრე DNS-ის უბრალოდ გასწორებას დასჭირდებოდა. Let's Encrypt მიმდინარე მაჩვენებლებს აქვეყნებს letsencrypt.org/docs/rate-limits მისამართზე, და ისინი იცვლება. გაასწორე მიზეზი, შემდეგ სცადე ერთხელ.

Wildcard-ები მეორე რამაა, რაზეც ხალხი კითხულობს. wildcard სერტიფიკატს HTTP ვალიდაციის ნაცვლად DNS ვალიდაცია სჭირდება, რაც ნიშნავს, რომ ორგანოს სჭირდება TXT ჩანაწერი, რომელიც მოთხოვნისას შენს DNS პროვაიდერთან იქმნება. რადგან აქაური ჩანაწერები შენს პროვაიდერთან ცხოვრობს და არა ჩვენს პანელში, პრაქტიკული პასუხია სლოტში იმ კონკრეტული სახელების დამატება, რომლებსაც იყენებ. სამი ქვედომენი სამი სახელია და დამატებითი სამუშაო არ არის. HTTPS და Let's Encrypt ახსნილი ვალიდაციის მეთოდებს სათანადოდ გადის.

რატომ ჩავარდა გაცემა#

იმ რიგით, როგორც ნამდვილად ხდება:

1. სახელი აქ ჯერ არ იხსნება. ყველაზე გავრცელებული დიდი სხვაობით. შეამოწმე dig @1.1.1.1-ით და არა ბრაუზერით. თუ ჩანაწერი სწორია და პასუხი არასწორი, ძველი TTL-ის შიგნით ხარ და პასუხი ლოდინია.

2. ის სხვაგან იხსნება. სხვა ჰოსტიდან გადმოხვედი და ძველი A ჩანაწერი ისევ ადგილზეა, ან ერთსა და იმავე სახელზე ორი A ჩანაწერია და resolver სიამოვნებით არასწორს აბრუნებს. სერტიფიკატი ვერ გაიცემა სახელზე, რომელიც სხვის სერვერზე მიუთითებს. წაშალე ძველი ჩანაწერი და მეორე არ დაამატო.

3. CAA ჩანაწერი კრძალავს. CAA ჩანაწერი ჩამოთვლის ორგანოებს, რომლებსაც შენი დომენისთვის გაცემა შეუძლიათ. თუ ერთი არსებობს და გამოყენებულ ორგანოს არ შეიცავს, ყველა მოთხოვნა უარყოფილია, სუფთად და გაუგებრად. შეამოწმე dig +short example.com CAA-ით. ან წაშალე, ან დაამატე სწორი ორგანო. ეს იშვიათია, მაგრამ უხილავია, სანამ არ მოძებნი.

4. წინ CDN დგას, არასწორ რეჟიმში. თუ შენს დომენს Cloudflare ან მსგავსი proxy-ს უკეთებს, origin ვალიდაციისთვის მაინც ხელმისაწვდომი უნდა იყოს. ჩვეულებრივი გამოსავალია ამ ჩანაწერზე proxy-ის გამორთვა - ნაცრისფერი ღრუბელი - სერტიფიკატის გაცემა, შემდეგ ისევ ჩართვა და CDN-ის origin რეჟიმის full ან strict-ზე დაყენება. საპირისპირო რიგით გააკეთებ - მიიღებ გადამისამართების ციკლს ან 526-ს. Cloudflare ვებსაიტებისთვის და გეიმ სერვერებისთვის ფარავს, რას აკეთებს და რას არა ნარინჯისფერი ღრუბელი.

5. AAAA ჩანაწერი არაფერზე მიუთითებს. ბრაუზერებიც და ვალიდაციის სერვერებიც IPv6-ს ამჯობინებენ, როცა AAAA ჩანაწერი არსებობს. თუ ის მისამართზე მიუთითებს, რომელიც შენი არ არის ან არ უსმენს, ცდა IPv4-ის ცდამდე ვარდება. წაშალე.

6. სლოტზე სახელი არ ემთხვევა ჩანაწერში სახელს. ბეჭდვითი შეცდომა, ბოლო წერტილი, ან app.example.com.example.com, რადგან DNS პროვაიდერი ზონის სახელს ამატებს ყველაფერს, რასაც სახელის ველში ჩაწერ. შეამოწმე ჩანაწერი ისე, როგორც პროვაიდერი გიჩვენებს შენახვის შემდეგ და არა ისე, როგორც აკრიფე.

HTTPS-ის მუშაობის შემდეგ: გადამისამართებები, header-ები და კლიენტის რეალური IP#

სერტიფიკატი ფინიშის ხაზი არ არის. ოთხი რამ უნდა დააყენო აპლიკაციაში proxy-ს უკან.

ენდე proxy-ს. სანამ ამას არ გააკეთებ, ყოველი მოთხოვნა proxy-ის საკუთარი მისამართიდან ჩანს, რაც არღვევს rate limiting-ს, abuse-ის დაბლოკვას, ანალიტიკასა და შენს access ლოგებს. Express-ში ეს არის app.set("trust proxy", 1); Django იყენებს SECURE_PROXY_SSL_HEADER-ს; Laravel-ს აქვს TrustProxies middleware; WordPress proxy-ს უკან ჩვეულებრივ რამდენიმე ხაზს საჭიროებს wp-config.php-ში, რომლებიც X-Forwarded-Proto-ს კითხულობს. Node.js აპის deploy GitHub-იდან Node-ის ვერსიას კონტექსტში გვიჩვენებს.

აპში HTTPS-ს ნუ აიძულებ. proxy შენს კონტეინერს ჩვეულებრივი HTTP-ით ელაპარაკება, ამიტომ აპლიკაცია, რომელიც ამოწმებს "უსაფრთხოა თუ არა ეს მოთხოვნა" და თუ არა, გადაამისამართებს, სამუდამოდ გადაამისამართებს. შეამოწმე X-Forwarded-Proto ან გადამისამართება proxy-ს დაუტოვე.

გაასწორე mixed content. HTTPS-ით მიწოდებული გვერდი, რომელიც სკრიპტს ან სურათს HTTP-ით ტვირთავს, ბრაუზერის მიერ იბლოკება, და სიმპტომი ნახევრად დახატული გვერდია და არა შეცდომა, რომელსაც შეამჩნევ. CMS-ისთვის ეს ჩვეულებრივ ბაზაში შენახული ძველი აბსოლუტური URL-ებია; გამოსავალია ძებნა და ჩანაცვლება მთელ კონტენტში, და WordPress-ის გადატანა ახალ ჰოსტზე ფარავს, როგორ გააკეთო ეს უსაფრთხოდ.

HSTS-თან ფრთხილად იყავი. Strict-Transport-Security header ბრაუზერებს ეუბნება, შენი დომენისთვის HTTP აღარასოდეს გამოიყენონ იმდენ ხანს, რამდენსაც max-age ამბობს. ეს კარგია, როცა ყველაფერი სტაბილურია, და მტკივნეული, სანამ ჯერ კიდევ რაღაცებს გადააქვს, რადგან ბრაუზერი, რომელმაც ის ქეშში შეინახა, უკან დაბრუნების საშუალებას არ მოგცემს. დაიწყე max-age=300-ით, გაზარდე ერთ წლამდე, როცა დარწმუნდები, და preload სიას ნუ შეეხები, სანამ დარწმუნებული არ ხარ, რომ ამ დომენს HTTP-ით არასოდეს მოემსახურები.

ცოცხალი საიტის გადატანა შუალედის გარეშე#

თანმიმდევრობა, რომელიც ძველ საიტს ემსახურებას უტოვებს, სანამ ახალი მზად არ იქნება:

1. ერთი დღით ადრე შეამცირე იმ ჩანაწერების TTL, რომლებსაც შეცვლი, 300-მდე.
2. ააგე საიტი ახალ სერვერზე და გამოსცადე DNS-ის რაიმე ცვლილებამდე შენი მანქანის hosts ფაილში ჩანაწერით, რომელიც დომენს ახალ მისამართზე აჩვენებს. შენ ახალ საიტს იხილავ, სანამ დანარჩენები ისევ ძველს ხედავენ.
3. მონაცემები ბოლოს გადააკოპირე. ფაილები, შემდეგ ბაზა, შემდეგ ის, რაც ამასობაში შეიცვალა. თუ შეგიძლია, ბოლო სინქრონიზაციისთვის გაყინე ჩაწერა ძველ საიტზე - ერთი საათი მხოლოდ კითხვისა უკეთესია, ვიდრე დაკარგული შეკვეთების დღე.
4. შეცვალე A ჩანაწერი. უყურე dig @1.1.1.1-ით, სანამ ახალი მისამართი არ დაბრუნდება.
5. დაელოდე სერტიფიკატს. ის ვერ გაიცემა, სანამ სახელი აქ არ მიუთითებს, ამიტომ DNS ცვლილების შემდეგ ერთი-ორი წუთის ფანჯარაა, როცა ვიზიტორებმა გაფრთხილება შეიძლება დაინახონ. გადართვა მშვიდ საათზე ამ ფანჯარას უფასოს ხდის.
6. ძველი ჰოსტი ერთი კვირა გააჩერე. Resolver-ები დიდი ხნით ქეშირებული პასუხებით, კორპორატიული DNS და რამდენიმე ჯიუტი მოწყობილობა იქ მაინც მივა. ეს ერთ დამატებით თვე ჰოსტინგს ჯდება და გიშველის კამათისგან, ვინ დაკარგა შეკვეთები.
7. დააბრუნე TTL 3600-ზე, როცა დაწყნარდები.

FAQ#

რამდენ ხანს სჭირდება DNS-ს განახლება?

შეცვლილი ჩანაწერის TTL-მდე, როგორც თითოეულ resolver-შია ქეშირებული - ე.ი. ერთი საათი ნაგულისხმევი 3600 TTL-ით, ოთხი საათი 14400-ით და დაახლოებით ხუთი წუთი, თუ ერთი დღით ადრე 300-მდე შეამცირე. სრულიად ახალი სახელი, რომელიც ადრე არავის მოუძებნია, მყისიერად იხსნება, რადგან არაფერია ქეშირებული, რაც ამოიწურება.

რატომ არ გაიცემა ჩემი სერტიფიკატი?

თითქმის ყოველთვის იმიტომ, რომ სახელი ჯერ ამ სერვერზე არ იხსნება, ან შენს წინა ჰოსტზე იხსნება. შეამოწმე dig +short yourname @1.1.1.1-ით შენი ქსელის გარედან. ამის შემდეგ მოძებნე CAA ჩანაწერი, რომელიც ორგანოს ზღუდავს, მოძველებული AAAA ჩანაწერი, CDN proxy, რომელიც origin-ს მალავს, და ბეჭდვითი შეცდომა ჩანაწერის სახელში. გაასწორე მიზეზი და სცადე ერთხელ და არა განმეორებით, რადგან ჩავარდნილი ვალიდაციები შეზღუდულია.

მჭირდება სერტიფიკატის ყოველწლიური განახლება?

არა. განახლება ავტომატურად მუშაობს მოქმედების ბოლო 21 დღეში. ერთადერთი, რაც მას აჩერებს, არის სახელის აქ გახსნის შეწყვეტა, და გრძელი განახლების ფანჯრის გამო ეს ჩავარდნა DNS ცვლილებიდან კვირების შემდეგ ჩნდება.

შემიძლია დომენის გამოყენება გეიმ სერვერთან?

დიახ, მაგრამ ჩვეულებრივი A ჩანაწერით სერვერის მისამართზე და არა proxy სლოტით - თამაშის ტრაფიკი HTTP არ არის. მოთამაშეები შემდეგ სახელსა და თამაშის პორტს უერთდებიან. Minecraft-ისთვის SRV ჩანაწერი დამატებით მოთამაშეებს საშუალებას აძლევს პორტი საერთოდ გამოტოვონ.

შემიძლია აქ დომენის ყიდვა?

არა. დომენებს არ ვარეგისტრირებთ და DNS ზონის რედაქტორს არ ვუშვებთ, ამიტომ შენი დომენი შენს რეგისტრატორთან ან DNS პროვაიდერთან რჩება და ჩანაწერებს იქ ქმნი. ჩვენგან მხოლოდ proxy სლოტზე ნაჩვენები მისამართი გჭირდება.

რაც შეეხება www-სა და apex-ს - ორი სერტიფიკატი მჭირდება?

ერთ სერტიფიკატს ორივე სახელის დაფარვა შეუძლია, მაგრამ ორივე უნდა დაემატოს სლოტს და ორივე უნდა იხსნებოდეს აქ. დაამატე ისინი, შემდეგ ერთი მეორეზე გადაამისამართე შენს აპლიკაციაში ან CMS-ში, რომ მხოლოდ ერთი იყოს კანონიკური, რაც შენს ანალიტიკასა და საძიებო შედეგებს ორად გაყოფისგან იცავს.