Как сделать localhost https

How to create a https server on localhost

I followed the tutorial below to create a https server https://docs.nodejitsu.com/articles/HTTP/servers/how-to-create-a-HTTPS-server/ and the program runs without errors but when I can not open https://localhost:8000 in my chrome it always get a ERR_SSL_PROTOCOL_ERROR

98.4k 91 91 gold badges 414 414 silver badges 889 889 bronze badges
asked Apr 28, 2017 at 10:02
3,851 6 6 gold badges 30 30 silver badges 61 61 bronze badges

Checking that https works is part of developing a website these days. Humble developers use localhost. I think the question is a good one.

– user1023602
Mar 9, 2018 at 11:51

It may be a somewhat better fit to Webmaster.SE, since it is more about setting up the environment, rather than coding as such.

Nov 23, 2020 at 19:51

10 Answers 10

Well one quick way to do this is with ngrok.

It’s really easy to use and only takes few secs to run. It is as simple as downloading your system version. Unzip and run ngrok.exe . It will open a command line type of window. Make sure your Apache server or the one you use is running.

Then to only listen on an HTTPS tunnel endpoint run the following

ngrok http -bind-tls=true site.dev:80 

or on whatever port you need https to be installed.

Open browser and type https://localhost/myApp you will see it works.

And if you type http://localhost/myApp it also works.

Hope this is helpful to anyone for a fast solution.

answered Oct 3, 2017 at 23:22
Balloon Fight Balloon Fight
671 8 8 silver badges 16 16 bronze badges

This doesn’t work. Error: You may only specify one port to tunnel to on the command line, got 3: [http -bind-tls=true site.dev:80]

Nov 16, 2017 at 4:31
what’s site.dev here?
Nov 20, 2017 at 12:45

@Pavan It looks like that is referring to, and I’m quoting from the ngrok —help docs, «forward traffic to example.com:8000». Or in this case, «to site.dev:80». I instead used ngrok http 3000 -subdomain=custom -bind-tls=true , then went to https://custom.ngrok.io on my local.

Jun 11, 2018 at 22:20
this is really awesome. Super easy solution. Thanks for sharing
Jan 10, 2019 at 22:32
Running this command on Windows gives unknown flag: —bind-tls , anyone know how to get past this?
Mar 7 at 15:40

I use Caddyserver with config like this:

:443 tls self_signed 

answered Mar 6, 2018 at 12:56
12.3k 3 3 gold badges 21 21 silver badges 26 26 bronze badges

You need to do two things:

• generate a self-signed SSL certificate and
• add it to the trusted certificates

Managed to do this on a macOS like so:

• In order to generate the SSL certificate, run the follosing command in a terminal (according to the instructions from Let’s Encrypt):

openssl req -x509 -out localhost.crt -keyout localhost.key \ -newkey rsa:2048 -nodes -sha256 \ -subj '/CN=localhost' -extensions EXT -config <( \ printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth") 

• And to add the certificate to the trusted certificates, ran the following command (suggested on this blog):

sudo security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" "/private/tmp/certs/certname.cer" 

answered May 10, 2019 at 8:59
1,311 2 2 gold badges 23 23 silver badges 36 36 bronze badges

Sorry, is the downvote due to the macOS specific solution? I thought it would be straight forward to find the way to achieve that on other OSs, having an example. Should I make the response OS-independent?

May 13, 2019 at 2:24
If it's not about that, please let me know if I'm wrong so that I won't make the same mistake.
May 13, 2019 at 7:06

I get an error: Error reading file /private/tmp/certs/certname.cer - I don't seem to have a certs folder ?

Jan 26, 2020 at 15:54
The first command does not generate the /private/tmp/certs/certname.cer file expected by the second.
Jul 18, 2022 at 21:02

If this is meant for testing and you don't need a valid cert (which seems to be the case since you're using "localhost") you can use a "self-signed" cert, just make sure to configure nginx to point to those.

I could explain the details, but there's actually a great post about that on Digital Ocean community tutorials:

just be sure to adapt the port (443) if you want to listen on 8000.

answered Apr 28, 2017 at 12:46
198 7 7 bronze badges

I finally set up my create-react-app https dev server

the reason why I'm doing this is to test device motion API on a mobile device.

brew install mkcert mkcert -install 

generate cert files.

mkcert -key-file ./.cert/key.pem -cert-file ./.cert/cert.pem "" 

use LAN IP address instead of "localhost", because we will open our https page on a mobile device that has connected to the same WiFi.

create a .env file to set env variables

HTTPS=true SSL_CRT_FILE=./.cert/cert.pem SSL_KEY_FILE=./.cert/key.pem 

start the dev server

npm start 

last but not least, install the cert file on the mobile device, the .pem file generated by mkcert is located in ~/Library/Application Support/mkcert in my case.

install cert file on an Android device

install cert file on an iOS device

serve the .pem file on a static server, and open the file address on Safari

answered Aug 18, 2020 at 9:15
3,851 6 6 gold badges 30 30 silver badges 61 61 bronze badges

Assuming you are using node.js, then http-server has -S or --ssl with -C and -K to enable https.

3,808 5 5 gold badges 32 32 silver badges 53 53 bronze badges
answered Jul 18, 2018 at 4:58
10.5k 11 11 gold badges 82 82 silver badges 133 133 bronze badges
Just tried this but http-server doesn't support passphrases so not sure how this would even work.
Oct 9, 2019 at 16:17

Keep in mind http-server is good for dev usage, but not necessarily good for production usage. Passphrases is not a must for TLS/SSL mode.

Oct 10, 2019 at 2:41
I wasn't using for production, I had issue creating self-signing certificates without passphrase
Oct 10, 2019 at 9:41
Then it will just work as I have been using it that way for a long time.
Oct 10, 2019 at 9:53

A very simple way is using local-ssl-proxy

 npm i -g local-ssl-proxy local-ssl-proxy --source 3001 --target 3000 

answered Jul 28, 2022 at 13:18
Seth Samuel Seth Samuel
285 2 2 silver badges 3 3 bronze badges

Is the idea here to run two processes in parallel? The simple HTTP server, and also the local-ssl-proxy?

Jan 18 at 11:30

The solution provided by Balloon Fight is absolutely what I was looking for and it works. But the command mentioned didn't work for me, so here is what worked for me.

I am using Lubuntu 20.04 LTS (64-bit).

Lubuntu is a lightweight Linux flavor using Debian, Ubuntu and LXDE as its base.

Steps for OSX would probably be similar. Steps for Windows and Ubuntu GNOME are also mentioned.

1. Go to ngrok and create an account.
2. Download ngrok and install.

For Windows, just unzip the file and open it. It'll run in cmd.

For Ubuntu GNOME, you would probably be able to run the file directly in terminal.

For Lubuntu (or if previous didn't work for you). Move the file as follows:

mv "path/to/ngrok" "/usr/bin/" 

1. If the file had directly opened up in terminal or cmd. Copy and paste the command from your profile on ngrok into cmd or terminal. The command looks like this: ./ngrok authtoken

If you are on Lubuntu, or if the file did not open directly in terminal. Change directory as follows:

cd "/usr/bin/" 

And then copy and paste the command from your profile on ngrok into terminal. The command looks like this:

./ngrok authtoken

1. Run your server. Nodejs or what you usually use.
2. If you are still in the same directory as 'ngrok' file. Copy and paste the following command into terminal or cmd: ngrok http 3000 -host-header="localhost:3000"

Change 3000 to the port you are using for the local server.

If you are out of 'ngrok' file's directory. Open it up in terminal or cmd.

For Lubuntu, use the following command to change directory:

cd "/usr/bin/" 

Then run the command:

ngrok http 3000 -host-header="localhost:3000" 

Change 3000 to the port you are using for the local server.

1. Copy and paste the HTTPS link, in the second 'Forwarding' row, to your browser.

The link looks something like this: https://12fab5c82c57.ngrok.io

For the next time you are required to do it. Just repeat step 4, 5 and 6.

https://localhost

2. Добавляем корневой сертификат в список доверенных

Ubuntu

• Network Security Services — Просмотр и управление сертификатами для браузеров
• Mozilla NSS library — Почему update-ca-certificates недостаточно
• local-cert-generator

sudo cp rootCA.pem /usr/local/share/ca-certificates/rootCA.crt sudo update-ca-certificates

Добавляем корневой сертификат в Firefox и Chrome

sudo apt install libnss3-tools openssl pkcs12 -export -out rootCA.pfx -inkey rootCA.key -in rootCA.crt pk12util -d sql:$HOME/.pki/nssdb -i rootCA.pfx certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n myapp-certificate -i rootCA.pem

Если не помогло:

• Firefox: Preferences → Privacy & Security → Certificates → View Certificates. → Authorities → Import. → выбираем rootCA.pem
• Chrome: Settings → Privacy and security → Manage certificates → Authorities → Import → выбираем rootCA.pem

Windows 7

Пуск → Панель управления → Свойства браузера → Содержание → Сертификаты → Доверенные корневые центры сертификации
Жмём кнопку «Импорт»

Windows 10

Start → Control Panel → Network and Internet → Internet Options → Content → Certificates → Trusted Root Certification Authorities
Import. → Next → Выбрать rootCA.pfx → Next → Заполнить Password → Next → Finish
Security warning → Yes

3. Создаём сертификат домена

Создаём файл server.csr.cnf со следующим содержимым.
В котором CN — доменное имя. Остальные поля заполняются как на шаге создания корневого сертификата.

[req] default_bits=2048 prompt=no default_md=sha256 distinguished_name=req_distinguished_name [req_distinguished_name] C=RU ST=Saint-Petersburg L=Saint-Petersburg O=RandomOrganization OU=RandomOrganizationUnit emailAddress[email protected] CN=localhost

Создаём файл v3.ext
Где DNS.1 — как поле CN в файле server.csr.cnf

authorityKeyIdentifier=keyid,issuer basicConstraints=CA:FALSE keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment subjectAltName = @alt_names [alt_names] DNS.1 = localhost

Генерируем доменный ключ

openssl req -new -sha256 -nodes -out server.csr -newkey rsa:2048 -keyout server.key -config server.csr.cnf

Генерируем доменный сертификат

openssl x509 -req -in server.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out server.crt -days 500 -sha256 -extfile v3.ext

Помещаем сгенерированные ключ и сертификат в директорию для Докер-контейнера

nginx/etc/ssl/certs/server.crt nginx/etc/ssl/private/server.key

4. Добавляем настройки для работы HTTPS в NGINX-конфиг

. . . http < server < - listen 7272; + listen 7272 ssl; + ssl_certificate /etc/ssl/certs/server.crt; + ssl_certificate_key /etc/ssl/private/server.key; . . .

5. Обновляем команду запуска NGINX Докер-контейнера

 docker run --rm -it -p 7272:7272 \ -v $(pwd)/nginx:/etc/nginx:ro \ + -v $(pwd)/nginx/etc/ssl/certs:/etc/ssl/certs \ + -v $(pwd)/nginx/etc/ssl/private:/etc/ssl/private \ --name myapp-nginx nginx

Дополнительные материалы

• Twitch Extensions Boilerplate
• How to get HTTPS working on your local development environment in 5 minutes

Сертификаты для localhost

Иногда разработчикам нужен сертификат для доменного имени “localhost” - для локальной разработки, или для распространения внутри нативных приложений для взаимодействия с web-приложением. Let’s Encrypt не предоставляет сертификатов для “localhost”, т.к. во-первых, у этого доменного имени нет определённого владельца, и во-вторых, нет домена первого уровня - например, “.com” или “.net”. Теоретически, возможно настроить доменное имя так, чтобы оно указывало на адрес 127.0.0.1 , и выпустить для него сертификат после прохождения проверки DNS. Тем не менее, есть более удачные решения. Тем не менее, есть более удачные решения.

Для локальной разработки

При разработке web-приложения обычно запускают локальный web-сервер (Apache, Nginx), настроенный на http://localhost:8000/ . Однако, браузеры по-разному обрабатывают HTTP- и HTTPS-запросы. На HTTPS-странице попытка загрузить Javascript по HTTP-протоколу будет заблокирована. Поэтому, при локальной разработке, используя HTTP, скрипты будут загружаться нормально, но после выкладки на рабочие HTTPS-серверы возникнут проблемы. Чтобы избежать такой ситуации, нужно настроить доступ по HTTPS на локальном web-сервере. Но как избавиться от постоянных сообщений об ошибке сертификата? Как увидеть “зелёный замОк” в адресной строке?

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

Для нативных приложений, взаимодействующих с web-приложениями

Время от времени, разработчики вынуждены выпускать загружаемые нативные приложения, для расширения функциональности и совместного использования с web-приложениями. Например, десктоп-приложения Dropbox и Spotify умеют сканировать файлы на дисках компьютера, что невозможно для web-приложений. Общий подход в реализации таких нативных приложений состоит в запуске локального web-сервера, и обмену данными с web-приложением через XMLHTTPRequest (XHR) или WebSockets. Web-приложения, как правило, используют HTTPS, поэтому XHR- или WebSockets-запросы по небезопасному протоколу HTTP будут отклонены. Это называется “блокировка смешаного контента” (Mixed Content Blocking). Для взаимодействия с web-приложением, нативное приложение должно быть безопасным.

С одной стороны, современные браузеры считают http://127.0.0.1:8000/ “потенциально заслуживающим доверие” URL-ом, потому что он локальный. Отправленный на 127.0.0.1 трафик гарантированно не уйдёт за пределы компьютера, соответственно, считается безопасным для перехвата по сети. Это означает, что если web-приложение использует HTTPS, а нативное приложение запущено на 127.0.0.1 , то обе программы могут успешно взаимодействовать по XHR. С другой стороны, для localhost это ещё не работает. А WebSocket-ы игнорируют и 127.0.0.1 , и localhost .

Возможно, вы захотите обойти эти ограничения, настроив указание произвольного доменного имени в глобальном DNS на адрес 127.0.0.1 (например, localhost.example.com ), выпустив сертификат для этого домена, распространяя сертификат и соответствующий ему закрытый ключ внутри нативного приложения, и настроив взаимодействие по https://localhost.example.com:8000/ вместо http://127.0.0.1:8000/ . Не делайте этого! Это подвергнет пользователей риску, и сертификат может быть отозван.

Используя доменное имя вместо IP-адреса, вы позволяете злоумышленникам запустить атаку Man in the Middle (MitM) в процессе поиска IP-адреса по доменному имени (DNS Lookup), и внедрить ответ, который укажет на другой IP-адрес. Атакующий может притвориться нативным приложением, подделывая запросы к web-приложению, что скомпрометирует аккаунт в web-приложении.

Успех атаки MitM возможен потому, что вы вынуждены распространять закрытый ключ для сертификата вместе с нативным приложением. Соответственно, любой, кто скачает это приложение, получит копию ключа. Этим вы скомпрометируете закрытый ключ, и Удостоверяющий Центр (УЦ) отзовёт сертификат, как только узнает об этом. У множества нативных приложений были отозваны их сертификаты из-за распространения закрытого ключа.

К сожалению, это сужает список безопасных способов взаимодействия нативных и web-приложений. И ситуация может ещё больше усложниться в недалёком будущем, если браузеры продолжат затруднять доступ к localhost.

Так же нужно отметить, что web-сервисы с доступом к нативному API изначально небезопасны, потому что сайты, которые вы не намеревались авторизовать, могут получить доступ к этому API. Если решите углубиться в изучение проблемы, обратите внимание на Cross-Origin Resource Sharing, использование заголовка ответа Access-Control-Allow-Origin, и надёжного HTTP-парсера. Потому как даже серверы, не прошедшие подтверждение, могут посылать предварительные запросы, эксплуатирующие уязвимости в HTTP-парсере.

Создание и поверка собственных сертификатов

Любой может выпустить собственный сертификат без обращения к ЦС. Единственное различие будет в том, что выпущенные вами сертификаты не будут приниматься кем-либо ещё. Для локальной разработки этого достаточно.

Простейший способ сгенерировать закрытый ключ и самоподписанный сертификат для localhost - выполнить следующую команду из пакета openssl:

openssl req -x509 -out localhost.crt -keyout localhost.key \ -newkey rsa:2048 -nodes -sha256 \ -subj '/CN=localhost' -extensions EXT -config <( \ printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth") 

Вы можете сконфигурировать локальный web-сервер, используя файлы localhost.crt и localhost.key, добавив localhost.crt в список доверенных корневых сертификатов.

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

Также, вы можете использовать доменное имя с точками внутри (например, www.localhost ), добавив в файл /etc/hosts как алиас адреса 127.0.0.1 . Этот подход чуть изменит способ обработки браузерами хранилища для cookie.

Let's Encrypt - это бесплатный, автоматизированный и открытый Центр Сертификации, созданный для вас некоммерческой организацией Internet Security Research Group (ISRG).

548 Market St, PMB 77519 , San Francisco , CA 94104-5401 , USA

Все письма и запросы отправляйте по адресу:

PO Box 18666 , Minneapolis , MN 55418-0666 , USA

• GitHub
• Twitter
• Mastodon

SSL-сертификат для Localhost

В настоящее время использование HTTPS становится обязательным для всех сайтов и веб-приложений. Однако в процессе разработки существует проблема, связанная с правильным тестированием. Естественно, Let's Encrypt и другие CA не выдают сертификаты для localhost, так как начиная с 1 ноября 2015 года форум CA/B проголосовал за прекращение их выдачи. Традиционно, есть два решения, описанные ниже.

Решение 1. Самоподписанный SSL

Самоподписанные сертификаты, сгенерированные через openssl. Вот самый простой способ сгенерировать закрытый ключ и самозаверяющий сертификат для localhost:

openssl req -x509 -out localhost.crt -keyout localhost.key \ -newkey rsa:2048 -nodes -sha256 \ -subj '/CN=localhost' -extensions EXT -config <( \ printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")

Но такой сертификат приведет к ошибкам доверия в браузерах, поскольку в доверенном хранилище нет соответствующего центра сертификации.

Решение 2: mkcert

Хитрость заключается в том, чтобы зарегистрировать новый домен, например localhost.example.com, который локально разрешается по 127.0.0.1 (в /etc/hosts), чтобы получить обычный сертификат для этого домена. Но такое мошенничество сомнительно с точки зрения безопасности - по крайней мере, для государственных служб такое разрешение настоятельно не рекомендуется из-за возможной атаки MiTM с изменением враждебного IP-адреса. Если мы ограничимся только локальной машиной, то это может быть подходящим вариантом, хотя есть и некоторые сомнения. Кроме того, такой сертификат может быть отозван. В любом случае, существует более простой и безопасный вариант (см. Ниже). Это mkcert, простая утилита для создания локально доверенных сертификатов с собственным центром сертификации. Он работает под всеми ОС и не требует настройки.

Для Linux

Сначала вы должны установить certutil.

sudo apt install libnss3-tools -или- sudo yum install nss-tools -или- sudo pacman -S nss

Затем сделайте:

brew install mkcert

или скомпилировать из источника:

go get -u github.com/FiloSottile/mkcert $(go env GOPATH)/bin/mkcert

Для MacOS

Следуйте следующей команде:

brew install mkcert brew install nss # если вы используете Firefox

Для Windows

Вы можете скачать собранные двоичные файлы или использовать один из менеджеров пакетов: Chocolatey или Scoop.

choco install mkcert -или- scoop install mkcert