Как заставить браузер доверять самоподписанному сертификату

Как заставить браузер доверять локальному SSL-сертификату?

Хотя есть similar вопросы и даже хорошие ответы, они либо не заботятся о локальном хосте. или спросите об одном конкретном варианте / решении (самоподписанный или CA).

Какие есть варианты? Как они сравниваются? Как мне это сделать?

4 ответа

tl; dr Создать сертификат, выданный собственным ЦС (см. сценарий ниже)

Вот что я нашел. Поправьте меня, где я ошибаюсь.

Есть ЦС (центры сертификации). Они выдают сертификаты (подписывают CSR) для других CA (промежуточных CA) или серверов (сертификаты конечных объектов). Некоторые из них являются корневыми авторитетами. У них есть самоподписанные сертификаты, выданные ими самими. То есть обычно существует цепочка доверия, которая идет от сертификата сервера к корневому сертификату. А за корневой сертификат не за что поручиться. Таким образом, ОС имеют хранилище корневых сертификатов (или хранилище политик доверия), общесистемный список доверенных корневых сертификатов. У браузеров есть собственные списки доверенных сертификатов, которые состоят из общесистемного списка и сертификатов, которым доверяет пользователь.

В Chromium вы управляете сертификатами в chrome: // settings / Certificates. В Firefox: Preferences > Privacy & Security > Certificates > View Certificates . У обоих есть вкладка Authorities, которая представляет собой список доверенных корневых сертификатов. И вкладка Серверы, список доверенных сертификатов серверов.

Чтобы получить сертификат, вы создаете CSR (запрос на подпись сертификата), отправьте его в CA. CA подписывает CSR, превращая его в доверенный сертификат в процессе.

Сертификаты и CSR — это набор полей с информацией и открытым ключом. Некоторые поля называются расширениями. Сертификат CA — это сертификат с basicConstraints = CA:true .

Вы можете проверить ошибки сертификата в Chromium в Developer Tools > Security .

Доверие к сертификатам в масштабах всей системы

Когда вы меняете хранилище корневых сертификатов ОС, вам необходимо перезапустить браузер. Вы меняете его с помощью:

trust помещает сертификаты CA в категорию «авторитетных» ( trust list ) или в категорию «другие записи» в противном случае. Сертификаты ЦС отображаются на вкладке «Авторитеты» в браузерах или на вкладке «Серверы».

Firefox не доверяет сертификатам сервера из корневого хранилища сертификатов ОС, в отличие от Chromium. Оба доверяют сертификатам CA из корневого хранилища сертификатов ОС.

Доверять сертификатам в браузере

В Chromium и Firefox вы можете добавлять (импортировать) сертификаты на вкладку Authorities. Если вы попытаетесь импортировать сертификат не CA, вы получите сообщение «Not a Certificate Authority». После выбора файла появляется диалоговое окно, в котором вы можете указать настройки доверия (когда доверять сертификату). Соответствующая настройка для обеспечения работы сайта — «Доверять этому сертификату для идентификации веб-сайтов».

В Chromium вы можете добавлять (импортировать) сертификаты на вкладке «Серверы». Но они попадают либо на вкладку «Центры» (сертификаты CA, и после выбора файла вам не открывается диалоговое окно настроек доверия), либо на вкладку «Другие» (если сертификат не CA).

В Firefox вы не можете точно добавить сертификат на вкладку «Серверы». Вы добавляете исключения. И там можно доверять сертификату без расширений (плохой).

Самозаверяющие расширения сертификатов

Моя система поставляется со следующими настройками по умолчанию (будут добавлены расширения) для сертификатов:

Кроме того, Chromium считает сертификат недействительным, если в нем нет subjectAltName = DNS:$domain .

Несамоподписанные расширения сертификатов

Когда браузеры доверяют самозаверяющему сертификату

Чтобы Chromium мог доверять самозаверяющему сертификату, он должен иметь basicConstraints = CA:true и subjectAltName = DNS:$domain . Для Firefox даже этого недостаточно:

Когда браузеры доверяют сертификату, выпущенному собственным ЦС

Firefox не нуждается в расширениях, но Chromium требует subjectAltName .

openssl шпаргалка

openssl genpkey -algorithm RSA -out «$domain».key — сгенерировать закрытый ключ (man)

openssl req -x509 -key «$domain».key -out «$domain».crt — создать самоподписанный сертификат (мужчина)

Без -subj он будет задавать вопросы относительно отличительного имени (DN), например, общего имени (CN), организации (O), населенного пункта (L). Вы можете ответить на них «заранее»: -subj «/CN=$domain/O=$org» .

Чтобы добавить расширение subjectAltName , вы должны либо иметь конфигурацию, в которой все это указано, либо добавить раздел в конфигурацию и указать openssl его имя с помощью переключателя -extensions :

openssl req -new -key «$domain».key -out «$domain».csr — генерировать CSR, может принимать опцию -subj (мужчина)

openssl x509 -req -in «$ домен» .csr -days 365 -out «$ домен» .crt \ -CA ca.crt -CAkey ca.key -CAcreateserial — подписать CSR (мужчина)

Не работает без -CAcreateserial . Он создает файл ca.srl , в котором хранится серийный номер последнего сгенерированного сертификата. Чтобы добавить subjectAltName , вам понадобится переключатель -extfile :

openssl req -in $domain.csr -text -noout — просмотреть CSR ( man )

openssl x509 -in $domain.crt -text -noout — просмотреть сертификат ( man )

Создать самоподписанный сертификат

(вам понадобится исключение в Firefox, чтобы оно работало)

Сгенерировать сертификат, выданный собственным ЦС

Конфигурация веб-сервера

P.S. Я использую Chromium 65.0.3325.162, Firefox 59.0 и openssl-1.1.0.g .

Windows

Очевидно, в Windows нет утилиты trust . В Windows есть два хранилища: хранилища локальных компьютеров и сертификатов текущего пользователя. Нет смысла использовать хранилище сертификатов Local Machine, поскольку мы работаем только для нашего текущего пользователя. Затем есть магазины. Два предопределенных из них представляют наибольший интерес: доверенные корневые центры сертификации и промежуточные центры сертификации. Обычно упоминается в командной строке как root и CA.

Вы можете получить доступ к Диспетчеру сертификатов Chrome, выполнив команду chrome: // settings /? Search = Manage% 20certificates и нажав Управление сертификатами. Наибольший интерес представляют вкладки «Доверенные корневые центры сертификации» и «Промежуточные центры сертификации».

Одним из способов управления сертификатами является командная строка :

Результаты следующие (для хранилищ локальных компьютеров и сертификатов текущего пользователя):

Другими вариантами могут быть двойной щелчок по сертификату в проводнике, импорт сертификатов из диспетчера сертификатов Chrome, использование оснастки MMC «Сертификаты» (запуск certmgr.msc ) или использование CertMgr.exe .

Для тех, у кого установлено grep , вот как быстро проверить, где находится сертификат:

Таким образом, установка сертификата CA в хранилище Current User> Trusted Root Certification Authorities кажется лучшим вариантом. И убедитесь , что не забыли перезапустить браузер.

Как выпустить самоподписанный 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 для локальной разработки?

Getting Chrome to accept self-signed localhost certificate

I have created a self-signed SSL certificate for the localhost CN. Firefox accepts this certificate after initially complaining about it, as expected. Chrome and IE, however, refuse to accept it, even after adding the certificate to the system certificate store under Trusted Roots. Even though the certificate is listed as correctly installed when I click «View certificate information» in Chrome’s HTTPS popup, it still insists the certificate cannot be trusted.

What am I supposed to do to get Chrome to accept the certificate and stop complaining about it?

50 Answers 50

For localhost only

Simply visit this link in your Chrome:

You should see highlighted text saying:

Allow invalid certificates for resources loaded from localhost

Options for other sites

Try typing thisisunsafe anywhere on the window, and the browser should let you visit the page.

For a local self-signed cert that avoids arcane commands, specialized knowledge, and manual steps, try mkcert from this answer.

This worked for me:

1. Using Chrome, hit a page on your server via HTTPS and continue past the red warning page (assuming you haven’t done this already).
2. Open up Chrome Settings > Show advanced settings > HTTPS/SSL > Manage Certificates .
3. Click the Authorities tab and scroll down to find your certificate under the Organization Name that you gave to the certificate.
4. Select it, click Edit (NOTE: in recent versions of Chrome, the button is now «Advanced» instead of «Edit»), check all the boxes and click OK. You may have to restart Chrome.

You should get the nice green lock on your pages now.

EDIT: I tried this again on a new machine and the certificate did not appear on the Manage Certificates window just by continuing from the red untrusted certificate page. I had to do the following:

1. On the page with the untrusted certificate ( https:// is crossed out in red), click the lock > Certificate Information. NOTE: on newer versions of chrome, you have to open Developer Tools > Security , and select View certificate .
2. Click the Details tab > Export . Choose PKCS #7, single certificate as the file format.
3. Then follow my original instructions to get to the Manage Certificates page. Click the Authorities tab > Import and choose the file to which you exported the certificate, and make sure to choose PKCS #7, single certificate as the file type.
4. If prompted certification store, choose Trusted Root Certificate Authorities
5. Check all boxes and click OK. Restart Chrome.

With only 5 openssl commands, you can accomplish this.

(Please don’t change your browser security settings.)

With the following code, you can (1) become your own CA, (2) then sign your SSL certificate as a CA. (3) Then import the CA certificate (not the SSL certificate, which goes onto your server) into Chrome/Chromium. (Yes, this works even on Linux.)

You can just copy the code below into a new file ("generate_certs.sh" for example), update the variable NAME and the DNS.2 and IP.1 and save the file. Make it executable (chmod +x generate_certs.sh) and run it and that is it. You will have at the end the myCA.pem and $NAME.crt and $NAME.key generated for you.

NB: For Windows, some reports say that openssl must be run with winpty to avoid a crash.

1. Become a CA
2. Sign your certificate using your CA cert+key
3. Import myCA.pem as an "Authority" (not into "Your Certificates") in your Chrome settings (Settings > Manage certificates > Authorities > Import)
4. Use the $NAME.crt and $NAME.key files in your server

You can check your work to ensure that the certificate is built correctly:

Extra steps for Mac:

1. Import the CA cert at "File > Import file", then also find it in the list, right click it, expand "> Trust", and select "Always"
2. Add extendedKeyUsage=serverAuth,clientAuth below basicConstraints=CA:FALSE , and make sure you set the "CommonName" to the same as $NAME when it’s asking for setup

Extra steps for Windows:

Convert the myCA.pem to myCA.pfx by doing:

Import the myCA.pfx into the Trusted Certificate Authorities of Windows by opening (double-click) the myCA.pfx file, selecting "Local Machine" and Next, Next again, enter the password and then Next, and select "Place all certificates int he following store:" and click on Browse and choose "Trusted Root Certification Authorities" and Next, and then Finish. Now your CA certificate is trusted by Windows so when you import and use the $NAME certificate it will be automatically trusted by Windows and Chrome.

Click anywhere on the page and type a BYPASS_SEQUENCE :

BYPASS_SEQUENCE	Chrome Version
thisisunsafe	65 — ?
badidea	62 — 64
danger	? — 61

You don’t need to look for input field, just type it. It feels strange but it works. I tried it on Mac High Sierra.

To double check if they changed it again, go to the latest Chromium source code. At the moment the BYPASS_SEQUENCE looks like this:

Now they have it camouflaged, but to see the real BYPASS_SEQUENCE you can run following line in a browser console.

OR

Alternatively to typing phrase you can paste the part of code in console

Update for Chrome 58+ (Released 2017-04-19)

As of Chrome 58, the ability to identify the host using only commonName was removed. Certificates must now use subjectAltName to identify their host(s). See further discussion here and bug tracker here. In the past, subjectAltName was used only for multi-host certs so some internal CA tools don’t include them.

If your self-signed certs worked fine in the past but suddenly started generating errors in Chrome 58, this is why.

So whatever method you are using to generate your self-signed cert (or cert signed by a self-signed CA), ensure that the server’s cert contains a subjectAltName with the proper DNS and/or IP entry/entries, even if it’s just for a single host.

For openssl, this means your OpenSSL config ( /etc/ssl/openssl.cnf on Ubuntu) should have something similar to the following for a single host:

or for multiple hosts:

In Chrome’s cert viewer (which has moved to "Security" tab under F12) you should see it listed under Extensions as Certificate Subject Alternative Name :

On the Mac, you can use the Keychain Access utility to add the self-signed certificate to the System keychain, and Chrome will then accept it. I found the step-by-step instructions here:

1. double-click the lock icon with an X and drag-and-drop the certificate icon to the desktop,
2. open this file (ending with a .cer extension); this opens the keychain application which allows you to approve the certificate.

On the Mac, you can create a certificate that’s fully trusted by Chrome and Safari at the system level by doing the following:

The above uses the following scripts, and a supporting file v3.ext , to avoid subject alternative name missing errors

If you want to create a new self signed cert that’s fully trusted using your own root authority, you can do it using these scripts.

create_root_cert_and_key.sh

create_certificate_for_domain.sh

v3.ext

One more step — How to make the self signed certs fully trusted in Chrome/Safari

To allow the self signed certificates to be FULLY trusted in Chrome and Safari, you need to import a new certificate authority into your Mac. To do so follow these instructions, or the more detailed instructions on this general process on the mitmproxy website:

You can do this one of 2 ways, at the command line, using this command which will prompt you for your password:

or by using the Keychain Access app:

1. Open Keychain Access
2. Choose "System" in the "Keychains" list
3. Choose "Certificates" in the "Category" list
4. Choose "File | Import Items. "
5. Browse to the file created above, "rootCA.pem", select it, and click "Open"
6. Select your newly imported certificate in the "Certificates" list.
7. Click the "i" button, or right click on your certificate, and choose "Get Info"
8. Expand the "Trust" option
9. Change "When using this certificate" to "Always Trust"
10. Close the dialog, and you’ll be prompted for your password.
11. Close and reopen any tabs that are using your target domain, and it’ll be loaded securely!

and as a bonus, if you need java clients to trust the certificates, you can do so by importing your certs into the java keystore. Note this will remove the cert from the keystore if it already exists, as it needs to update it in case things change. It of course only does this for the certs being imported.

import_certs_in_current_folder_into_java_keystore.sh

Linux

If you’re using Linux, you can also follow this official wiki pages:

• click the lock icon with an X,
• choose Certificate Information
• go to Details tab
• Click on Export. (save as a file)

Now, the following command will add the certificate (where YOUR_FILE is your exported file):

To list all your certificates, run the following command:

If it still doesn’t work, you could be affected by this bug: Issue 55050: Ubuntu SSL error 8179

P.S. Please also make sure that you have libnss3-tools , before you can use above commands.

If you don’t have, please install it by:

As a bonus, you can use the following handy scripts:

Troubleshooting

Run Chrome with —auto-ssl-client-auth parameter

UPDATE 11/2017: This answer probably won’t work for most newer versions of Chrome.

UPDATE 02/2016: Better Instructions for Mac Users Can be Found Here.

On the site you want to add, right-click the red lock icon in the address bar:

Click the tab labeled Connection, then click Certificate Information

Click the Details tab, the click the button Copy to File. . This will open the Certificate Export Wizard, click Next to get to the Export File Format screen.

Choose DER encoded binary X.509 (.CER), click Next

Click Browse. and save the file to your computer. Name it something descriptive. Click Next, then click Finish.

Open Chrome settings, scroll to the bottom, and click Show advanced settings.

Under HTTPS/SSL, click Manage certificates.

Click the Trusted Root Certification Authorities tab, then click the Import. button. This opens the Certificate Import Wizard. Click Next to get to the File to Import screen.

Click Browse. and select the certificate file you saved earlier, then click Next.

Select Place all certificates in the following store. The selected store should be Trusted Root Certification Authorities. If it isn’t, click Browse. and select it. Click Next and Finish

Click Yes on the security warning.

UPDATED Apr 23/2020

Recommended by the Chromium Team

Quick Super-Easy Solution

There is a secret bypass phrase that can be typed into the error page to have Chrome proceed despite the security error: thisisunsafe (in earlier versions of Chrome, type badidea, and even earlier, danger). DO NOT USE THIS UNLESS YOU UNDERSTAND EXACTLY WHY YOU NEED IT!

(NOTE that window.atob(‘dGhpc2lzdW5zYWZl’) resolves to thisisunsafe )

For background about why the Chrome team changed the bypass phrase (the first time):

If all else fails (Solution #1)

For quick one-offs if the «Proceed Anyway» option is not available, nor the bypass phrase is working, this hack works well:

Allow certificate errors from localhost by enabling this flag (note Chrome needs a restart after changing the flag value):

If the site you want to connect to is localhost , you’re done. Otherwise, setup a TCP tunnel to listen on port 8090 locally and connect to broken-remote-site.com on port 443, ensure you have socat installed and run something like this in a terminal window:

socat tcp-listen:8090,reuseaddr,fork tcp:broken-remote-site.com:443

If all else fails (Solution #2)

Similar to «If all else fails (Solution #1)», here we configure a proxy to our local service using ngrok. Because you can either access ngrok http tunnels via TLS (in which case it is terminated by ngrok with a valid certificate), or via a non-TLS endpoint, the browser will not complain about invalid certificates.

Download and install ngrok and then expose it via ngrok.io :

ngrok will start up and provide you a host name which you can connect to, and all requests will be tunneled back to your local machine.

If you’re on a mac and not seeing the export tab or how to get the certificate this worked for me:

1. Click the lock before the https://
2. Go to the «Connection» tab

Click «Certificate Information»

Now you should see this:

Drag that little certificate icon do your desktop (or anywhere).

Double click the .cer file that was downloaded, this should import it into your keychain and open Keychain Access to your list of certificates.

In some cases, this is enough and you can now refresh the page.

Now reload the page in question and it should be problem solved! Hope this helps.

Edit from Wolph

To make this a little easier you can use the following script (source):

Save the following script as whitelist_ssl_certificate.ssh :

Make the script executable (from the shell):

Run the script for the domain you want (simply copy/pasting the full url works):

For a test environment

You can use —ignore-certificate-errors as a command line parameter when launching chrome (Working on Version 28.0.1500.52 on Ubuntu).

This will cause it to ignore the errors and connect without warning. If you already have a version of chrome running, you will need to close this before relaunching from the command line or it will open a new window but ignore the parameters.

I configure Intellij to launch chrome this way when doing debugging, as the test servers never have valid certificates.

I wouldn’t recommend normal browsing like this though, as certificate checks are an important security feature, but this may be helpful to some.

WINDOWS JUN/2017 Windows Server 2012

I followed @Brad Parks answer. On Windows you should import rootCA.pem in Trusted Root Certificates Authorities store.

I did the following steps:

Then, in my case I have a self hosted web app, so I need to bind certificate with IP address and port, certificate should be on MY store with private key information, so I exported to pfx format.

With mmc console (File/Add or Remove Snap-ins/Certificates/Add/Computert Account/LocalComputer/OK) I imported pfx file in Personal store.

Later I used this command to bind certificate (you could also use HttpConfig tool):

appid=GUID (your choice)

First I tried to import the certificate «device.crt» on Trusted Root Certificates Authorities in different ways but I’m still getting same error:

But I realized that I should import certificate of root authority not certificate for domain. So I used mmc console (File/Add or Remove Snap-ins/Certificates/Add/Computert Account/LocalComputer/OK) I imported rootCA.pem in Trusted Root Certificates Authorities store.

Restart Chrome and et voilà it works.

Or with IP address:

The only thing I could not achieve is that, it has obsolete cipher (red square on picture). Help is appreciated on this point.

With makecert it is not possible add SAN information. With New-SelfSignedCertificate (Powershell) you could add SAN information, it also works.

Filippo Valsorda wrote a cross-platform tool, mkcert , to do this for lots of trust stores. I presume he wrote it for the same reason that there are so many answers to this question: it is a pain to do the "right" thing for SubjectAltName certificates signed by a trusted root CA.

mkcert is included in the major package management systems for Windows, macOS, and several Linux flavors. It is also mentioned in the Chromium docs in Step 4 of Testing Powerful Features.

mkcert

mkcert is a simple tool for making locally-trusted development certificates. It requires no configuration.

As someone has noted, you need to restart ALL of Chrome, not just the browser windows. The fastest way to do this is to open a tab to.

Add the CA certificate in the trusted root CA Store.

Go to chrome and enable this flag!

At last, simply use the *.me domain or any valid domains like *.com and *.net and maintain them in the host file. For my local devs, I use *.me or *.com with a host file maintained as follows:

Add to host. C:/windows/system32/drivers/etc/hosts

Note: If the browser is already opened when doing this, the error will keep on showing. So, please close the browser and start again. Better yet, go incognito or start a new session for immediate effect.

Are you sure the address the site is being served up as is the same as the certificate? I had the same problems with Chrome and a self-signed cert, but in the end I found it was just incredibly picky about the validation of the domain name on the cert (as it should be).

Chrome doesn’t have it’s own cert store and uses Window’s own. However Chrome provides no way to import certs into the store so you should add them via IE instead.

Also take a look at this for a couple of different approaches to creating self-signed certs (I’m assuming you’re using IIS as you haven’t mentioned).

I went down the process of using what bjnord suggested which was: Google Chrome, Mac OS X and Self-Signed SSL Certificates

What is shown in the blog did not work.

However, one of the comments to the blog was gold:

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain site.crt

You’ll need to follow the blog on how to get the cert file, after that you can use the command above and should be good to go.

The GUI for managing SSL certs on Chromium on Linux did NOT work properly for me. However, their docs gave the right answer. The trick was to run the command below that imports the self-signed SSL cert. Just update the name of the <certificate-nickname> and certificate-filename.cer , then restart chromium/chrome.

From the Docs:

• Debian/Ubuntu: sudo apt-get install libnss3-tools

• Fedora: su -c «yum install nss-tools»

• Gentoo: su -c «echo ‘dev-libs/nss utils’ >> /etc/portage/package.use && emerge dev-libs/nss» (You need to launch all commands below with the nss prefix, e.g., nsscertutil .) Opensuse: sudo zypper install mozilla-nss-tools

Allowing insecure localhost work fine via this method chrome://flags/#allow-insecure-localhost

Just that you need to create your development hostname to xxx.localhost.

To create a self signed certificate in Windows that Chrome v58 and later will trust, launch Powershell with elevated privileges and type:

Once you do this, the certificate will be saved to the Local Computer certificates under the Personal\Certificates store.

You want to copy this certificate to the Trusted Root Certification Authorities\Certificates store.

One way to do this: click the Windows start button, and type certlm.msc . Then drag and drop the newly created certificate to the Trusted Root Certification Authorities\Certificates store per the below screenshot.

For Fedora, Ubuntu, Linux, if you’re getting example.com Not a Certification authority error when adding the certificate using the gui to add a new root authority. If you want to trust a server self signed certificate, it cannot make mention of an invalid authority. even if that’s itself. I’ve only managed to make it work by trusting my authority and using that authorities key to sign server certificates.

Here’s the self signed CA certificate that it accepted. This is the only way that I found works to get around cert_authority_invalid , I tried for hours to get it to accept a self signed end point certificate, no cigar. The UI will accept self signed authorities, as long as it’s declared CA:TRUE . After that, all certs signed by that key with the correct DN will be accepted by chrome without needing to add them independently.

openssl req -new -x509 -extensions v3_req -days 8440 -config ca.conf -key rockstor.key -out rockstor.cert

openssl req -new -x509 -extensions v3_req -days 8440 -config config.conf -key rockstor.key -out rockstor.cert

If that doesn’t work:

chrome://restart to actually restart

Try to get more details on the error using firefox, it tends to explain errors better. while chrome will say, ERR_CERTIFICATE_INVALID, firefox will throw: MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY.

Remember that chrome now requires Subject Alternate Name and nearly ignores CN.

For others:

certutil -d sql:$HOME/.pki/nssdb -A -t «P,,» -n <nickname> -i <my.crt> // For server sertificates

For Firefox, the UI adding an exception certificate does work and it will trust it once you do that.

Perhaps you have funky settings in /etc/pki/tls/openssl.cnf which get merged with your config.

perhaps you’re no adding an extension to the config or command line, such as v3_req

Note, my method bypasses the need for a CSR by just signing the certificates with the authority key and adding details for the dev servers. CSR’s allow more keys for actual security.

I tried everything, but chrome requires an authority with basicconstraints CA:true set. And server certificates must all be singed by a valid Authority. even if that’s just another certificate that the signed themselves with CA:true.

Как заставить браузер доверять самоподписанному сертификату

В статье «Введение в NSS, одна статья, статья» подробно представил библиотеку паролей NSS. Многие разработчики, возможно, не слышали о NSS, но все они знают, что библиотека сертификатов CREDID в библиотеке паролей NSS (CERT9.DB или CERT8. DB), многие программные и услуги могут ссылаться на надежный сертификат NSS. Как самые популярные браузеры, Chrome и Firefox, они также могут использовать NSS для доверия библиотеки корневых сертификатов на разных платформах, поэтому в этой статье рассказывается о соответствующих знаниях, чтобы каждый обладал более глубоким пониманием библиотеки паролей NSS. Библиотека сертификатов — это Очень важно для понимания протокола HTTPS.

Несколько тем в этой статье на несколько тем:

• Вы знаете, откуда берется библиотека сертификации Chrome?
• Вы знаете, откуда берется библиотека сертификации Firefox?
• Знаете ли вы, как генерировать сертификат, согласованный?
• Вы знаете, как экспортировать сертификат?
• Вы знаете, как обновить сертификат в Chrome и Firefox?

Поскольку существует много контента, в этой статье объясняется две статьи. В первой статье в основном объясняется библиотека сертификатов корневых сертификатов NSS и Windows и вводит, как обновить корневой сертификат в Chrome. Второе объяснение того, как обновить библиотеку сертификатов NSS Root и как обновить библиотеку сертификатов Root, используемая Firefox.

Заранее, в следующей таблице перечислены некоторые ситуации различных платформ и различных браузеров, цитирующих библиотеки сертификации кредита.

Платформа браузера	Windows	Unix
Chrome	Используйте библиотеку сертификации сертификатов Windows Trust	Используйте библиотеку сертификатов сертификатов траста NSS
Firefox	Используйте библиотеку сертификатов сертификатов траста NSS	Используйте библиотеку сертификатов сертификатов траста NSS

Что такое библиотека сертификатов доверенного корня

При подключении веб -сайта HTTPS сервер отправит цепочку сертификатов, но есть только цепочка сертификатов. Клиент не может завершить проверку сертификата. Должен быть сертификат для завершения итерации сертификации подписи. То есть клиент должен Доверьте корневой сертификат, чтобы построить основу для доверия, где корневой сертификат?

• На платформе Windows Microsoft имеет специальную карту.
• На платформе Linux программное обеспечение и услуги обычно используют библиотеку сертификатов NSS Root.
• На платформе Apple есть также специализированные библиотеки сертификации.

Чтобы вести бизнес, каждое учреждение CA должно подать заявку на внедрение своих собственных корневых сертификатов в различные платформы. Если заявка отклонена, учреждение CA не сможет вести бизнес.

В области программного обеспечения с открытым исходным кодом, библиотека сертификатов NSS Root является наиболее популярной, так много программного обеспечения и сервисов будет использовать библиотеку сертификатов NSS Root. Какова причина? Ключевой лежит в прозрачности. NSS строго рассмотрел и решительно устраняет существование нелегальных сертификатов CA Root.

Для обычных пользователей и разработчиков, в целом, они не могут связаться с библиотекой сертификатов доверенного корневого сертификата, но в некоторых случаях также возможно, что вы можете обновить локальную библиотеку сертификатов с доверенным корнем, например:

(1) В среде разработки следует избегать использования онлайн -сертификатов, поскольку сертификат и личный ключ следует сохранить вместе. Поскольку среда разработки относительно хаотична, легко утечь частные ключи, что повышает риски безопасности.

В этом случае можно сгенерировать самопознательный сертификат. Поскольку браузер не доверяет сертификату, он всегда вызывает риски безопасности при посещении веб -сайта. Чтобы избежать частых пособий, вы можете вручную добавить сертификат в достойный корень браузера. может быть добавлен вручную в заслуживающий доверия корень браузера. В библиотеке сертификатов.

(2) Создайте частное CA в рамках предприятия, а затем выпустите сертификат своему собственному бизнесу. Эта ситуация очень распространена. Например, некоторые внутренние системы управления могут использовать самооценку сертификата для снижения стоимости заявки на сертификат. Риск может быть добавлен в библиотеку надежных сертификатов браузера.

Снова интерпретируйте Certutil и Cert9.db

В библиотеке достоверных корневых сертификатов NSS все данные хранятся в cert9.db (cert9.db, key4.db и pkcs11.txt) или cert8.db (cert8.db, key3.db, secmod.db)), из После версии Firefox 58 используется cert9.db.

Так где же cert9.db и cert8.db? Это два разных формата данных. CERT9.DB представляет базу данных SQLITE, а CERT8.DB представляет унаследованную базу данных безопасности.

Используйте инструмент командной строки Certutil для управления сертификатом NSS, а установка очень проста:

Прежде всего, чтобы проверить файл cert9.db через заказ: эти сертификаты:

Параметр -d представляет файл cert9.db для каталога. -L Отображает файл сертификата, содержащийся в файле, а вывод выглядит следующим образом:

Библиотека сертификатов Windows Root

Cryptoapi Microsoft также очень популярен. Как и NSS, это библиотека кода нижнего кода криптографии. Он также включает в себя библиотеку сертификатов системных сертификатов. Хром IE, Edge и Windows Platforms использует библиотеку системных сертификатов Microsoft.

Библиотека сертификатов системного сертификата Microsoft хранится в реестре. Поскольку компьютер Windows является многоупонентной операционной системой и позволяет управлять стратегией групповой стратегии, инвентаризация сертификата корневого сертификата находится в нескольких позициях, таких как::

• CERT_SYSTEM_STORE_CURRENT_USER, представляющий текущего пользователя входа в систему, соответствующий сертификат хранится в каталоге HKEY_CURRENT_USER \ Software \ Microsoft \ SystemCertificates.
• CERT_SYSTEM_STORE_LOCAL_MACHINE, представляющий машину, соответствующий сертификат хранится в HKEY_LOCAL_MACHINE \ Software \ Microsoft \ SystemCertification of.
• CERT_SYSTEM_CURRENT_USER_GROUP_POLICY, представляющий текущую стратегию группы пользователей, соответствующий сертификат хранится в каталоге HKEY_CURRENT_USER \ Software \ POLICIES \ Microsoft \ SystemCertificates.

При обычных обстоятельствах библиотека сертификатов корневых сертификатов, используемая пользователем посадки системы Windows, хранится в CERT_SYSTEM_STORE_CURRENT_USER. Microsoft предоставляет сертификат управления инструментами CERTMGR (фактически работа в работе). Введите инструмент управления сертификатом CERTMGR в Командная строка CMD. Как показано ниже:

Для нас наиболее заинтересованным является «Агентство по выдаче сертификатов доверенного корня». Все сертификаты хранятся в этом каталоге. Вы можете добавить или удалить корневую сертификат через инструмент Certmgr и командную строку CERTMGR.

Как обновить сертификат в системе Windows

В системе Windows Chrome использует сертификат Windows Root. Если вам нужно обновить, есть два способа. Первый — использовать сертификат управления CERTMGR. Второе — сосредоточиться на введении меню функции Chrome для обновления сертификата. Фактически, функциональное меню эквивалентно выполнению операций управления CERTMGR, просто интегрируя эту функцию в Chrome.

Как выпустить самоподписанный 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 для локальной разработки?

Как заставить браузер доверять локальному SSL-сертификату?

Хотя есть similar вопросы и даже хорошие ответы, они либо не заботятся о локальном хосте. или спросите об одном конкретном варианте / решении (самоподписанный или CA).

Какие есть варианты? Как они сравниваются? Как мне это сделать?

4 ответа

tl; dr Создать сертификат, выданный собственным ЦС (см. сценарий ниже)

Вот что я нашел. Поправьте меня, где я ошибаюсь.

Есть ЦС (центры сертификации). Они выдают сертификаты (подписывают CSR) для других CA (промежуточных CA) или серверов (сертификаты конечных объектов). Некоторые из них являются корневыми авторитетами. У них есть самоподписанные сертификаты, выданные ими самими. То есть обычно существует цепочка доверия, которая идет от сертификата сервера к корневому сертификату. А за корневой сертификат не за что поручиться. Таким образом, ОС имеют хранилище корневых сертификатов (или хранилище политик доверия), общесистемный список доверенных корневых сертификатов. У браузеров есть собственные списки доверенных сертификатов, которые состоят из общесистемного списка и сертификатов, которым доверяет пользователь.

В Chromium вы управляете сертификатами в chrome: // settings / Certificates. В Firefox: Preferences > Privacy & Security > Certificates > View Certificates . У обоих есть вкладка Authorities, которая представляет собой список доверенных корневых сертификатов. И вкладка Серверы, список доверенных сертификатов серверов.

Чтобы получить сертификат, вы создаете CSR (запрос на подпись сертификата), отправьте его в CA. CA подписывает CSR, превращая его в доверенный сертификат в процессе.

Сертификаты и CSR — это набор полей с информацией и открытым ключом. Некоторые поля называются расширениями. Сертификат CA — это сертификат с basicConstraints = CA:true .

Вы можете проверить ошибки сертификата в Chromium в Developer Tools > Security .

Доверие к сертификатам в масштабах всей системы

Когда вы меняете хранилище корневых сертификатов ОС, вам необходимо перезапустить браузер. Вы меняете его с помощью:

trust помещает сертификаты CA в категорию «авторитетных» ( trust list ) или в категорию «другие записи» в противном случае. Сертификаты ЦС отображаются на вкладке «Авторитеты» в браузерах или на вкладке «Серверы».

Firefox не доверяет сертификатам сервера из корневого хранилища сертификатов ОС, в отличие от Chromium. Оба доверяют сертификатам CA из корневого хранилища сертификатов ОС.

Доверять сертификатам в браузере

В Chromium и Firefox вы можете добавлять (импортировать) сертификаты на вкладку Authorities. Если вы попытаетесь импортировать сертификат не CA, вы получите сообщение «Not a Certificate Authority». После выбора файла появляется диалоговое окно, в котором вы можете указать настройки доверия (когда доверять сертификату). Соответствующая настройка для обеспечения работы сайта — «Доверять этому сертификату для идентификации веб-сайтов».

В Chromium вы можете добавлять (импортировать) сертификаты на вкладке «Серверы». Но они попадают либо на вкладку «Центры» (сертификаты CA, и после выбора файла вам не открывается диалоговое окно настроек доверия), либо на вкладку «Другие» (если сертификат не CA).

В Firefox вы не можете точно добавить сертификат на вкладку «Серверы». Вы добавляете исключения. И там можно доверять сертификату без расширений (плохой).

Самозаверяющие расширения сертификатов

Моя система поставляется со следующими настройками по умолчанию (будут добавлены расширения) для сертификатов:

Кроме того, Chromium считает сертификат недействительным, если в нем нет subjectAltName = DNS:$domain .

Несамоподписанные расширения сертификатов

Когда браузеры доверяют самозаверяющему сертификату

Чтобы Chromium мог доверять самозаверяющему сертификату, он должен иметь basicConstraints = CA:true и subjectAltName = DNS:$domain . Для Firefox даже этого недостаточно:

Когда браузеры доверяют сертификату, выпущенному собственным ЦС

Firefox не нуждается в расширениях, но Chromium требует subjectAltName .

openssl шпаргалка

openssl genpkey -algorithm RSA -out «$domain».key — сгенерировать закрытый ключ (man)

openssl req -x509 -key «$domain».key -out «$domain».crt — создать самоподписанный сертификат (мужчина)

Без -subj он будет задавать вопросы относительно отличительного имени (DN), например, общего имени (CN), организации (O), населенного пункта (L). Вы можете ответить на них «заранее»: -subj «/CN=$domain/O=$org» .

Чтобы добавить расширение subjectAltName , вы должны либо иметь конфигурацию, в которой все это указано, либо добавить раздел в конфигурацию и указать openssl его имя с помощью переключателя -extensions :

openssl req -new -key «$domain».key -out «$domain».csr — генерировать CSR, может принимать опцию -subj (мужчина)

openssl x509 -req -in «$ домен» .csr -days 365 -out «$ домен» .crt \ -CA ca.crt -CAkey ca.key -CAcreateserial — подписать CSR (мужчина)

Не работает без -CAcreateserial . Он создает файл ca.srl , в котором хранится серийный номер последнего сгенерированного сертификата. Чтобы добавить subjectAltName , вам понадобится переключатель -extfile :

openssl req -in $domain.csr -text -noout — просмотреть CSR ( man )

openssl x509 -in $domain.crt -text -noout — просмотреть сертификат ( man )

Создать самоподписанный сертификат

(вам понадобится исключение в Firefox, чтобы оно работало)

Сгенерировать сертификат, выданный собственным ЦС

Конфигурация веб-сервера

P.S. Я использую Chromium 65.0.3325.162, Firefox 59.0 и openssl-1.1.0.g .

Windows

Очевидно, в Windows нет утилиты trust . В Windows есть два хранилища: хранилища локальных компьютеров и сертификатов текущего пользователя. Нет смысла использовать хранилище сертификатов Local Machine, поскольку мы работаем только для нашего текущего пользователя. Затем есть магазины. Два предопределенных из них представляют наибольший интерес: доверенные корневые центры сертификации и промежуточные центры сертификации. Обычно упоминается в командной строке как root и CA.

Вы можете получить доступ к Диспетчеру сертификатов Chrome, выполнив команду chrome: // settings /? Search = Manage% 20certificates и нажав Управление сертификатами. Наибольший интерес представляют вкладки «Доверенные корневые центры сертификации» и «Промежуточные центры сертификации».

Одним из способов управления сертификатами является командная строка :

Результаты следующие (для хранилищ локальных компьютеров и сертификатов текущего пользователя):

Другими вариантами могут быть двойной щелчок по сертификату в проводнике, импорт сертификатов из диспетчера сертификатов Chrome, использование оснастки MMC «Сертификаты» (запуск certmgr.msc ) или использование CertMgr.exe .

Для тех, у кого установлено grep , вот как быстро проверить, где находится сертификат:

Таким образом, установка сертификата CA в хранилище Current User> Trusted Root Certification Authorities кажется лучшим вариантом. И убедитесь , что не забыли перезапустить браузер.

Браузер не принимает самоподписанный сертификат

Я пишу HTTPS Proxy (наподобие Fiddler, только для конкретного домена). Соответственно, для просмотра зашифрованного трафика нужно организовать передачу браузеру сертификата с совпадающим именем нужного домена. Сертификат предварительно установлен как доверенный, т.к. является самоподписанным (через Мастер импорта сертификатов Windows; просмотреть можно в настройках сертификатов браузера в списках Личные и Доверенные корневые центры сертификации). Однако, при попытке соединения браузер даёт ошибку ERR_CERT_COMMON_NAME_INVALID и пишет что соединение не защищено.

В адресной строке указано, что сертификат не действителен, но если там же открыть настройки переданного сертификата, то в окне свойств пишется, что сертификат действителен. Хм.

P.S.: Использую Google Chrome

ERR_CERT_COMMON_NAME_INVALID говорит о том, что сертификат вы сделали не для того домена или сайта, к которому пытаетесь подключиться.

Chrome последних версий не смотрит на commonName , а смотрит только на subjectAltName . Если вы при создании сертификата через конфиг не указываете SAN, то вы получаете такую ошибку.