این صفحه راهنمایی برای راه اندازی HTTPS در سرورهای شما ارائه می دهد که شامل مراحل زیر می شود:
- ایجاد یک جفت کلید عمومی/خصوصی 2048 بیتی RSA.
- ایجاد یک درخواست امضای گواهی (CSR) که کلید عمومی شما را جاسازی می کند.
- به اشتراک گذاری CSR خود با مرجع صدور گواهی (CA) برای دریافت گواهی نهایی یا زنجیره گواهی.
- گواهی نهایی خود را در مکانی غیر قابل دسترسی از طریق وب مانند
/etc/ssl(لینوکس و یونیکس) یا هر جایی که IIS نیاز دارد (ویندوز) نصب کنید.
کلیدها و درخواست های امضای گواهی را ایجاد کنید
این بخش از برنامه خط فرمان openssl که با اکثر سیستم‌های Linux، BSD و Mac OS X ارائه می‌شود، برای تولید کلیدهای خصوصی و عمومی و CSR استفاده می‌کند.
یک جفت کلید عمومی/خصوصی ایجاد کنید
برای شروع، یک جفت کلید RSA 2048 بیتی ایجاد کنید. یک کلید کوتاه‌تر را می‌توان با حملات حدس‌زنی brute-force شکست، و کلیدهای طولانی‌تر از منابع غیرضروری استفاده می‌کنند.
برای ایجاد یک جفت کلید RSA از دستور زیر استفاده کنید:
openssl genrsa -out www.example.com.key 2048
این خروجی زیر را می دهد:
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
درخواست امضای گواهی را ایجاد کنید
در این مرحله، کلید عمومی و اطلاعات مربوط به سازمان و وب سایت خود را در یک درخواست امضای گواهی یا CSR جاسازی می کنید. دستور openssl از شما متادیتای مورد نیاز را می خواهد.
اجرای دستور زیر:
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
خروجی زیر
You are about to be asked to enter information that will be incorporated
into your certificate request
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
برای اطمینان از اعتبار CSR، این دستور را اجرا کنید:
openssl req -text -in www.example.com.csr -noout
پاسخ باید به شکل زیر باشد:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
...
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
...
CSR خود را به یک مرجع گواهی ارسال کنید
مقامات گواهی (CA) مختلف از شما می خواهند که CSR های خود را به روش های مختلف به آنها ارسال کنید. اینها می تواند شامل استفاده از یک فرم در وب سایت آنها یا ارسال CSR از طریق ایمیل باشد. برخی از CA، یا فروشندگان آنها، حتی ممکن است برخی یا تمام فرآیندها را خودکار کنند، از جمله، در برخی موارد، جفت کلید و تولید CSR.
CSR را به CA خود ارسال کنید و دستورالعمل های آنها را دنبال کنید تا گواهی نهایی یا زنجیره گواهی خود را دریافت کنید.
CA های مختلف مقادیر متفاوتی را برای خدمات ضمانت کلید عمومی شما دریافت می کنند.
همچنین گزینه هایی برای نگاشت کلید شما به بیش از یک نام DNS، از جمله چندین نام متمایز (مثلاً همه example.com، www.example.com، example.net، و www.example.net) یا نام های "wildcard" وجود دارد. به عنوان *.example.com .
گواهی‌ها را در تمام سرورهای فرانت‌اند خود در مکانی غیرقابل دسترس مانند /etc/ssl (لینوکس و یونیکس) یا هر جایی که IIS (ویندوز) نیاز دارد، کپی کنید.
HTTPS را در سرورهای خود فعال کنید
فعال کردن HTTPS در سرورهای شما یک گام مهم در تامین امنیت صفحات وب شما است.
- از ابزار پیکربندی سرور موزیلا برای تنظیم سرور خود برای پشتیبانی از HTTPS استفاده کنید.
- به طور منظم سایت خود را با تست سرور SSL Qualys آزمایش کنید و مطمئن شوید که حداقل A یا A+ را دریافت می کنید.
در این مرحله، شما باید یک تصمیم عملیاتی حیاتی بگیرید. یکی از موارد زیر را انتخاب کنید:
- یک آدرس IP متمایز را به هر نام میزبانی که سرور وب شما از آن محتوا ارائه می دهد اختصاص دهید.
- از هاست مجازی مبتنی بر نام استفاده کنید.
اگر از آدرس‌های IP مجزا برای هر نام میزبان استفاده کرده‌اید، می‌توانید از HTTP و HTTPS برای همه مشتریان پشتیبانی کنید. با این حال، اکثر اپراتورهای سایت از میزبانی مجازی مبتنی بر نام برای حفظ آدرس های IP و به دلیل راحت تر بودن آن به طور کلی استفاده می کنند.
اگر از قبل سرویس HTTPS را روی سرورهای خود ندارید، اکنون آن را فعال کنید (بدون هدایت HTTP به HTTPS. برای اطلاعات بیشتر به تغییر مسیر HTTP به HTTPS مراجعه کنید). وب سرور خود را برای استفاده از گواهی هایی که خریداری و نصب کرده اید پیکربندی کنید. ممکن است مولد پیکربندی موزیلا برای شما مفید باشد.
اگر نام هاست یا زیر دامنه های زیادی دارید، هر کدام باید از گواهی مناسب استفاده کنند.
اکنون و به طور منظم در طول عمر سایت خود، پیکربندی HTTPS خود را با تست سرور SSL Qualys بررسی کنید. سایت شما باید نمره A یا A+ داشته باشد. با هر چیزی که باعث نمره پایین تر می شود به عنوان یک اشکال برخورد کنید و سخت کوش باشید، زیرا حملات جدید علیه الگوریتم ها و پروتکل ها همیشه در حال توسعه هستند.
URL های درون سایت را نسبی کنید
اکنون که سایت خود را بر روی HTTP و HTTPS ارائه می‌دهید، بدون در نظر گرفتن پروتکل، همه چیز باید تا حد امکان روان کار کند. یک عامل مهم استفاده از URL های نسبی برای لینک های درون سایتی است.
اطمینان حاصل کنید که URL های داخلی و URL های خارجی به پروتکل خاصی بستگی ندارند. از مسیرهای نسبی استفاده کنید یا پروتکل را مانند //example.com/something.js کنار بگذارید.
ارائه صفحه‌ای که حاوی منابع HTTP با استفاده از HTTPS است می‌تواند مشکلاتی ایجاد کند . هنگامی که یک مرورگر با صفحه ای امن با استفاده از منابع ناامن مواجه می شود، به کاربران هشدار می دهد که صفحه کاملاً ایمن نیست و برخی از مرورگرها از بارگیری یا اجرای منابع HTTP خودداری می کنند که باعث شکسته شدن صفحه می شود. با این حال، می توانید با خیال راحت منابع HTTPS را در یک صفحه HTTP قرار دهید. برای راهنمایی بیشتر در مورد رفع این مشکلات، به رفع محتوای مختلط مراجعه کنید.
دنبال کردن پیوندهای مبتنی بر HTTP به صفحات دیگر در سایت شما نیز می تواند تجربه کاربر را از HTTPS به HTTP تنزل دهد. برای رفع این مشکل، URL های درون سایت خود را تا حد امکان نسبی کنید، و آنها را با پروتکل (بدون پروتکل، با //example.com شروع می شود) یا مربوط به میزبان (که فقط با مسیر شروع می شود، مانند /jquery.js ) نسبی کنید. .
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p>از URL های داخلی نسبی استفاده کنید.
<h1>Welcome To Example.com</h1> <script src="//example.com/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="//img.example.com/logo.png"/>; <p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>یا از URL های داخلی مرتبط با پروتکل استفاده کنید.
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p> <p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>در صورت امکان از URL های HTTPS برای پیوند به سایت های دیگر استفاده کنید.
برای جلوگیری از اشتباه، پیوندهای خود را با یک اسکریپت به روز کنید، نه با دست. اگر محتوای سایت شما در یک پایگاه داده است، اسکریپت خود را بر روی یک نسخه توسعه دهنده از پایگاه داده تست کنید. اگر محتوای سایت شما فقط از فایل های ساده تشکیل شده است، اسکریپت خود را بر روی یک نسخه توسعه دهنده از فایل ها تست کنید. طبق معمول، تغییرات را فقط پس از عبور از QA به تولید فشار دهید. می توانید از اسکریپت برام ون دام یا چیزی شبیه به آن برای شناسایی محتوای ترکیبی در سایت خود استفاده کنید.
هنگام پیوند دادن به سایت های دیگر (برخلاف گنجاندن منابع از آنها)، پروتکل را تغییر ندهید. شما کنترلی بر نحوه عملکرد آن سایت ها ندارید.
برای راحت‌تر کردن مهاجرت برای سایت‌های بزرگ، URLهای مرتبط با پروتکل را توصیه می‌کنیم. اگر هنوز مطمئن نیستید که می توانید HTTPS را به طور کامل اجرا کنید، مجبور کردن سایت شما به استفاده از HTTPS برای همه منابع فرعی می تواند نتیجه معکوس داشته باشد. احتمالاً یک دوره زمانی وجود دارد که در آن HTTPS برای شما جدید و عجیب است و سایت HTTP همچنان باید مثل همیشه خوب کار کند. با گذشت زمان، انتقال را کامل کرده و در HTTPS قفل خواهید کرد (دو بخش بعدی را ببینید).
اگر سایت شما به اسکریپت ها، تصاویر یا منابع دیگری که از طرف شخص ثالث ارائه می شود، مانند CDN یا jquery.com بستگی دارد، دو گزینه دارید:
- برای این منابع از URL های مرتبط با پروتکل استفاده کنید. اگر شخص ثالث HTTPS سرویس نمی دهد، از آنها بخواهید که این کار را انجام دهند. اکثر آنها از جمله jquery.com در حال حاضر این کار را انجام می دهند.
- منابع را از سروری که کنترل می‌کنید، که HTTP و HTTPS را ارائه می‌دهد، ارائه دهید. به هر حال این اغلب ایده خوبی است، زیرا در این صورت کنترل بهتری بر ظاهر، عملکرد و امنیت سایت خود خواهید داشت و برای حفظ امنیت سایت خود نیازی به اعتماد به شخص ثالث ندارید.
HTTP را به HTTPS هدایت کنید
برای اینکه به موتورهای جستجو بگویید از HTTPS برای دسترسی به سایت شما استفاده کنند، با استفاده از تگ‌های <link rel="canonical" href="https://…"/> در سر هر صفحه یک پیوند متعارف قرار دهید.
Strict Transport Security و کوکی های ایمن را روشن کنید
در این مرحله، شما آماده «قفل کردن» استفاده از HTTPS هستید:
- از HTTP Strict Transport Security (HSTS) برای جلوگیری از هزینه تغییر مسیر 301 استفاده کنید.
- همیشه پرچم امن را روی کوکی ها تنظیم کنید.
ابتدا، از Strict Transport Security استفاده کنید تا به مشتریان بگویید که همیشه باید با استفاده از HTTPS به سرور شما متصل شوند، حتی زمانی که یک مرجع http:// را دنبال می کنند. این کار حملاتی مانند SSL Stripping را شکست می دهد و از هزینه رفت 301 redirect که در تغییر مسیر HTTP به HTTPS فعال کرده بودیم جلوگیری می کند.
برای روشن کردن HSTS، هدر Strict-Transport-Security را تنظیم کنید. صفحه HSTS OWASP دارای پیوندهایی به دستورالعمل ها برای انواع مختلف نرم افزار سرور است.
اکثر وب سرورها توانایی مشابهی برای اضافه کردن هدرهای سفارشی ارائه می دهند.
همچنین مهم است که مطمئن شوید مشتریان هرگز کوکی ها (مانند احراز هویت یا تنظیمات برگزیده سایت) را از طریق HTTP ارسال نمی کنند. به عنوان مثال، اگر قرار باشد کوکی احراز هویت کاربر به صورت متن ساده نمایش داده شود، ضمانت امنیتی شما برای کل جلسه او از بین می‌رود، حتی اگر همه چیز را درست انجام داده باشید!
برای جلوگیری از این امر، برنامه وب خود را طوری تغییر دهید که همیشه پرچم امن را روی کوکی هایی که تنظیم می کند، تنظیم کند. این صفحه OWASP نحوه تنظیم پرچم امن در چندین چارچوب برنامه را توضیح می دهد . هر فریم ورک appl راهی برای تنظیم پرچم دارد.
اکثر وب سرورها یک ویژگی تغییر مسیر ساده را ارائه می دهند. از 301 (Moved Permanently) استفاده کنید تا به موتورهای جستجو و مرورگرها نشان دهید که نسخه HTTPS متعارف است و کاربران خود را از HTTP به نسخه HTTPS سایت خود هدایت کنید.
رتبه بندی جستجو
گوگل از HTTPS به عنوان یک شاخص کیفیت جستجوی مثبت استفاده می کند. گوگل همچنین راهنمای نحوه انتقال، جابجایی یا مهاجرت سایت خود را با حفظ رتبه جستجو منتشر می کند. بینگ همچنین دستورالعمل هایی را برای مدیران وب سایت منتشر می کند.
کارایی
وقتی لایه‌های محتوا و برنامه به خوبی تنظیم شده باشند (برای مشاوره به کتاب‌های استیو سادرز مراجعه کنید)، نگرانی‌های باقی‌مانده مربوط به عملکرد TLS معمولاً نسبت به هزینه کلی برنامه کوچک است. همچنین می توانید این هزینه ها را کاهش داده و مستهلک کنید. برای مشاوره در مورد بهینه‌سازی TLS، به شبکه‌سازی مرورگر با کارایی بالا توسط ایلیا گریگوریک، و همچنین کتاب آشپزی OpenSSL و SSL و TLS ضد گلوله ایوان ریستیک مراجعه کنید.
در برخی موارد، TLS می‌تواند عملکرد را بهبود بخشد، عمدتاً در نتیجه امکان‌پذیر کردن HTTP/2. برای اطلاعات بیشتر، به سخنرانی کریس پالمر در مورد عملکرد HTTPS و HTTP/2 در کروم Dev Summit 2014 مراجعه کنید.
سرصفحه های ارجاع دهنده
وقتی کاربران پیوندهایی را از سایت HTTPS شما به سایت های HTTP دیگر دنبال می کنند، نمایندگان کاربر سرصفحه ارجاع را ارسال نمی کنند. اگر این یک مشکل است، چندین راه برای حل آن وجود دارد:
- سایر سایت ها باید به HTTPS مهاجرت کنند. اگر سایت‌های داور بخش فعال کردن HTTPS در سرورهای شما را در این راهنما تکمیل می‌کنند، می‌توانید پیوندهای موجود در سایت خود را به سایت آنها از
http://بهhttps://تغییر دهید یا از پیوندهای مرتبط با پروتکل استفاده کنید. - برای حل انواع مشکلات با سرصفحه های Referer، از استاندارد جدید Referrer Policy استفاده کنید.
درآمد تبلیغات
اپراتورهای سایتی که از طریق نمایش تبلیغات از سایت خود کسب درآمد می کنند، می خواهند مطمئن شوند که مهاجرت به HTTPS باعث کاهش نمایش تبلیغات نمی شود. با این حال، به دلیل نگرانی‌های امنیتی محتوای مختلط، HTTP <iframe> در صفحه HTTPS کار نمی‌کند. تا زمانی که تبلیغ‌کنندگان از طریق HTTPS منتشر نکنند، اپراتورهای سایت نمی‌توانند بدون از دست دادن درآمد تبلیغاتی به HTTPS مهاجرت کنند. اما تا زمانی که اپراتورهای سایت به HTTPS مهاجرت کنند، تبلیغ‌کنندگان انگیزه کمی برای انتشار HTTPS دارند.
می‌توانید با استفاده از تبلیغ‌کنندگانی که خدمات تبلیغاتی را از طریق HTTPS ارائه می‌کنند، روند شکستن این بن‌بست را شروع کنید و از تبلیغ‌کنندگانی که اصلاً به HTTPS سرویس نمی‌دهند بخواهید حداقل آن را به یک گزینه تبدیل کنند. ممکن است لازم باشد تکمیل URL های IntraSite را نسبی به تعویق بیندازید تا زمانی که تعداد کافی تبلیغ کننده به درستی کار کنند.