Self signed certificate что это
Как выпустить самоподписанный SSL сертификат и заставить ваш браузер доверять ему
Все крупные сайты давно перешли на протокол https. Тенденция продолжается, и многие наши клиенты хотят, чтобы их сайт работал по защищенному протоколу. А если разрабатывается backend для мобильного приложения, то https обязателен. Например, Apple требует, чтобы обмен данными сервера с приложением велся по безопасному протоколу. Это требование введено с конца 2016 года.
На production нет проблем с сертификатами. Обычно хостинг провайдер предоставляет удобный интерфейс для подключения сертификата. Выпуск сертификата тоже дело не сложное. Но во время работы над проектом каждый разработчик должен позаботиться о сертификате сам.
В этой статье я расскажу, как выпустить самоподписанный SSL сертификат и заставить браузер доверять ему.
Чтобы выпустить сертификат для вашего локального домена, понадобится корневой сертификат. На его основе будут выпускаться все остальные сертификаты. Да, для каждого нового top level домена нужно выпускать свой сертификат. Получить корневой сертификат достаточно просто.
Сначала сформируем закрытый ключ:
Затем сам сертификат:
Нужно будет ввести страну, город, компанию и т.д. В результате получаем два файла: rootCA.key и rootCA.pem
Переходим к главному, выпуск самоподписанного сертификата. Так же как и в случае с корневым, это две команды. Но параметров у команд будет значительно больше. И нам понадобится вспомогательный конфигурационный файл. Поэтому оформим все это в виде bash скрипта create_certificate_for_domain.sh
Первый параметр обязателен, выведем небольшую инструкцию для пользователя.
Создадим новый приватный ключ, если он не существует или будем использовать существующий:
Запросим у пользователя название домена. Добавим возможность задания “общего имени” (оно используется при формировании сертификата):
Чтобы не отвечать на вопросы в интерактивном режиме, сформируем строку с ответами. И зададим время действия сертификата:
В переменной SUBJECT перечислены все те же вопросы, который задавались при создании корневого сертификата (страна, город, компания и т.д). Все значение, кроме CN можно поменять на свое усмотрение.
Сформируем csr файл (Certificate Signing Request) на основе ключа. Подробнее о файле запроса сертификата можно почитать в этой статье.
Формируем файл сертификата. Для этого нам понадобится вспомогательный файл с настройками. В этот файл мы запишем домены, для которых будет валиден сертификат и некоторые другие настройки. Назовем его v3.ext. Обращаю ваше внимание, что это отдельный файл, а не часть bash скрипта.
Да, верно, наш сертификат будет валидным для основного домена, а также для всех поддоменов. Сохраняем указанные выше строки в файл v3.ext
Возвращаемся в наш bash скрипт. На основе вспомогательного файла v3.ext создаем временный файл с указанием нашего домена:
Переименовываем сертификат и удаляем временный файл:
Скрипт готов. Запускаем его:
Получаем два файла: mysite.localhost.crt и device.key
Теперь нужно указать web серверу пути к этим файлам. На примере nginx это будет выглядеть так:
Запускаем браузер, открываем https://mysite.localhost и видим:
Браузер не доверяет этому сертификату. Как быть?
Нужно отметить выпущенный нами сертификат как Trusted. На Linux (Ubuntu и, наверное, остальных Debian-based дистрибутивах) это можно сделать через сам браузер. В Mac OS X это можно сделать через приложение Keychain Access. Запускаем приложение и перетаскиваем в окно файл mysite.localhost.crt. Затем открываем добавленный файл и выбираем Always Trust:
Обновляем страницу в браузере и:
Успех! Браузер доверяет нашему сертификату.
Сертификатом можно поделиться с другими разработчиками, чтобы они добавили его к себе. А если вы используете Docker, то сертификат можно сохранить там. Именно так это реализовано на всех наших проектах.
Делитесь в комментариях, используете ли вы https для локальной разработки?
Максим Ковтун,
Руководитель отдела разработки
Шпоры по сертификатам X.509
Чудище обло, озорно, огромно, стозевно и лаяй.
Кстати что общего между LDAP, SNMP и X.509 ну кроме того, что им еще не скоро предстоит собрать стадионы фанатов? Их объединяет ASN.1 — мета-язык описания объектов древности. Если бы эти технологии создавали сейчас, в ход бы пошли XML, DTD или какой-нибудь другой ML. Но в то время стандарты создавались титанами, для которых даже SNMP был простым делом.
Словарный запас
Определение X.509 сертификатов есть в архиве ITU-T
Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1 SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.
Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.
Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.
Вторая функция сертификатов X.509 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией. Полгода назад Гугл пригрозил компании Симантек, что перестанет доверять их сертификатам из-за того, что те выпустили аж 30,000 неисправных сертификатов.
Номенклатура сертификатов
Давайте рассмотрим, какие сертификаты X.509 встречаются в природе, если рассматривать их по расположению в пищевой цепочке доверия.
По степени крутизны дороговизны и надежности сертификаты делятся на 3 вида: DV, OV и EV.
Редко, кто на это готов раскошелиться. Навскидку Яндекс, StackOverflow.com и Хабр могут жить и без него. Но те, кто готов пойти ради этого на жертвы должны выполнить следующие требования:
По свои свойствам сертификаты бывают следующих типов.
В России понятие КС квалифицированного сертификата определено законодательно в связи с доступом к ГосУслугам. По ссыске Хабрапост с былиной об извлечении персональных данных из КС.
Откуда берутся сертификаты?
Еще совсем недавно было всего 2 способа заполучить X.509 сертификат, но времена меняются и с недавнего времени есть и третий путь.
Для первого сценария достаточно пары команд и чтобы 2 раза не вставать создадим сертификат с алгоритмом эллиптических кривых. Первым шагом нужно создать закрытый ключ. Считается, что шифрование с алгоритмом эллиптических кривых дает больший выхлоп, если измерять в тактах CPU, либо байтах длины ключа. Поддержка ECC не определена однозначно в TLS Openssl имеет огромное количество опций и команд. Man страница не очень полезна, справочник удобнее использовать так:
Следует серия вопросов, чтобы было чем запомнить поля owner и issuer
Конвертируем связку ключей из проприетарного формата в PKCS12.
Смотрим на результат:
LetsEncrypt
Сценарий №1 — найти следующего в связке
Так и есть, SKI сертификат DigiCert имеет то же значение.
Сценарий №2 — используй subjectAltnName, Люк
Откройте файл openssl.cnf и в секции req добавьте следующие линии.
Далее, в секции [ v3_ca ] укажите.
А дальше все как обычно, создаем закрытый ключ и подписываем сертификат.
TARUN LALWANI
SSL certificates allow us to secure communication between the server and user. Unfortunately SSL certificates are a bit costly and are not prefered to be bought for development environments. This is where self-signed certificates come into picture.
Creating a Self-signed certificate
We can create a self-signed certificate using the openssl command
The command would ask certain set of questions depending on the openssl config, once we have answered these questions the certificate would be created
These certificates are called wild card certificates. We can even have a multi-domain certificate as well which would list multiple domains in a single certficate. The cost of certificate is dependent on type. With single domain costing the least, then multi-domain and wildcard certificate being the costliest one.
Testing the certificates using Nginx
Now let us run a simple nginx server using openresty/openresty docker image and use these ssl certificates
nginx.conf
site.conf
Then we run the files in a openresty docker image using below command
Next we create a host entry of our host IP as dev.tarunlalwani.com and test it using curl
Certificate validation and errors
Now that we have used a self-signed certificate, let’s look at some of the validation issues.
Python
So in python also we get an error for such a self-signed certificate. We can fix the same by passing the certificate
NodeJS
To fix this error we need to use the CA file again
So each language will have a way for you to specify the CA file for validating the certificate.
So why does it work for other sites like google, microsoft and not for ours? The reason is that these sites purchase SSL certificate from a signing authority. The signing authority could be certified from another authority. The ones on the top of chain are called “Root Authority”, the sub authorities are called “Intermediate” and the last certificate in the chain is our site certificate.
If you need a more detailed explaination of this, please have a look at this article
Since these public signing authority certificates are already trusted on the system, it is easier for us code against these sites. For our self-signed one we need to adjust our code.
But there is a way for us to trust these certificates on the system and avoid having to change our code for SSL validation.
Trusting certificates on System
Once we trust the certificate on a system, the curl command with validate the certificate directly from system. We will see how to trust the certificate on different OSes
Alpine
Ubuntu and Debian
Ubuntu and Debian OS will also work the same way as alpine except that the ca-certificates package will be installed using apt or apt-get
CentOS
CentOS is a bit different in terms of the certificate paths
Note: You may need to use sudo for these commands if you are not using the root user
Windows
Mac OS X
Mac OS uses keychains and there are multiple chains in a system. You can either add it to the System keychain using below command (accessible to all users on the system)
or you can add it to the current users login chain
Note: This will make the certificate accepted by curl, but not by Python, NodeJS and few other languages. The reason is that these languages don’t use the Mac OS keychain for validating the certificates. This article wouldn’t go into the details about the same. But see references links for more information on the issue
Self-signed certificate using Root Certificate
We generated and self signed our certificate earlier using openssl command. The problem with this approach is that, every time we generated a new certificate it needs to be trusted individually on the machine.
Instead of generating seperate self-signed certificates for our site, we can generate a Root Certificate and then use that certificate to Sign other cetificates.
Once we have generated a root certificate, we can trust that root certificate on our system. Once the root certificate is trusted every individual certificate that we sign using the root certificate will be trusted automatically.
This makes it possible to generate certificates on the fly, tools like Charles Web proxy, Fiddler use this technique for intercepting SSL traffic.
So now we will look at how to create a root certificate and then generate a certificate signed using our root certificate
Below is a sample shell script to make it easy to generate these certificates
sslcerts.sh
It is very simple to use. To generate the root certifcate, edit the file and update your details.
Generating the Root Certificate
Generating a Certificate signed using Root CA
The above certificate would not work on Chrome 58 or higher and give below error
This server could not prove that it is dev.tarunlalwani.com; its security certificate is from [missing_subjectAltName]. This may be caused by a misconfiguration or an attacker intercepting your connection.
You can see that chrome shows the two possible DNS names for this certificate and validates our certificate as the Root CA is trusted
References
It took me a time to bring everything into a single article and keep it simple. This article wouldn’t have been possible without below references
Своё Certificate Authority — в 5 OpenSSL команд
Зачем это нужно?
Представим, у нас есть два сервера, работают они себе, и переодически они хотят, что-то друг у друга спросить по протоколу HTTP/HTTPS.
Протокол HTTP не безопасен и логично использовать протокол HTTPS для общения меду серверами.
Для организации такого общения нам нужно 2 SSL сертификата.
Если сервера пренадлежат одной организации, то может быть проще и безопасней подписывать сертификаты самостоятельно, а не покупать.
Создаем наше CA
Первая команда создаёт корневой ключ
Для меня ключ 2048 bit достаточен, если вам хочется, вы можете использовать ключ 4096 bit.
Вторая команда создаёт корневой сертификат.
Отвечать на вопросы тут можно как душе угодно.
10000 дней срок его годности, примерно столько живет сертификат, которым google требует подписывать андроид приложения для Google Play. Если вы паникер, подписывайте на год или два.
Все! Теперь мы можем создавать сертификаты для наших серверов и устанавливать корневой сертификат на наши клиентские машины.
Создаем сертификат подписаный нашим СА
Создаем запрос на сертификат.
Тут важно указать имя сервера: домен или IP (например домен server101.mycloud)
и подписать запрос на сертификат нашим корневым сертификатом.
Теперь на клиенты нужно установить корневой сертификат rootCA.crt
rootCA.crt — можно давать друзьям, устанавливать, копировать не сервера, выкладывать в публичный доступ
rootCA.key — следует держать в тайне
Установка корневого сертификата
Windows
IE, Chrome — используют репозиторий сертификатов Windows.
Мой путь к нему таков:
Chrome — Settings — Manage Certificates…
Выбрать таб Trusted Root Certificate Authorities — Import — rootCA.crt
перезапустить Chrome
FireFox на виндоус имеет свой репозиторий.
Java имеет свой репозиторий.
Mac OS X
Safari, FireFox, Chrome — используют системный репозиторий.
Запускаем KeyChain Access.
Идём в меню File — Import Items (login или System) — выбираем файл rootCA.crt.
Когда нас спросят, отвечаем — Always Trust.
Для вашего личного Safari достаточно выбрать login.
В Ubuntu
Программа сервера на Go
Программа сервера на Go myserver.go, которая использует наш подписаный сертификат.
запустив программу на сервере server101.mycloud, ваш броузер не будет ругаться на страничку https://server101.mycloud:8443/, и откроет её как родную, если перед этим вы установили rootCA.crt в систему как корневой сертификат.
Создание Self-Signed Certificate при помощь С#
Просто о NET | создано: 17.06.2020 | опубликовано: 17.06.2020 | обновлено: 03.12.2021 | просмотров: 2367
Несколько способов создания self-signed сертификата, в том числе и на C#.
Что такое Self-Signed сертификат
Для чего Self-Signed сертификат
На самом деле может быть множество вариантов использования Self-Signed сертификата. Один из, это когда у вас есть локальная сеть (или сеть организации) и в этой сети есть сервер сертификации. Хм.. Согласен, не совсем подходяший пример, потому что если нужно для организации, это будет делать системный администратор вашей организации. Если только для тестовых целей, например для подписания IdentityServer4.
Варианты создания
Приведу пару-тройку ссылок где вы можете выбрать способ создания Self-Signed сертификата.
Создаем Self-Signed сертификат через C#
Пока можете не образщать на этот класс внимания, будет понятнее позже, или точнее из сода следующего метода:
Это статичный метод, его можно «завернуть» в nuget-пакет и устанавливать в те приложения, где вам потребуется. Я же, не так часто использую Self-Signed сертификаты, поэтому я просто себе создал файл в LinqPad (и ниже я приведу его целиком).
Вызов метода для генерации Self-Signed сертификата:
Создаем конфигурацию и отправляем ее в метода MakeCert. Всё просто, не правда ли?
Linqpad файл целиком
Вот и всё. Выбирайте удобный для вас способ и «клепайте» свои сертификаты. Но помните, что эти сертификаты будут сертификатами только для вас. 🙂
2005-2021 © Calabonga SOFT
Все права защищены по лицензии Creative Commons BY-NC-SA
При использовании материалов сайта ссылка на ресурс обязательна! v.5.1.50