Docker-образы с поддержкой гост-сертификатов в openssl, curl, php, nginx

Содержание:

Подпись сертификатов OpenSSL

Допустим, у вас есть приватный ключ и запрос на подпись, фактически, открытый ключ. Теперь вам нужно его подписать чтобы получить сертификат, который можно использовать. Тут есть несколько вариантов. Можно отправить csr файл на подпись какому-либо центру сертификации, например, LetsEncrypt. Можно подписать сертификат тем же ключом, с помощью которого он был создан, и третий вариант — создать свой центр сертификации.

Первый способ я рассматривать не буду. Здесь все просто. Либо используете утилиту сервиса, либо заполняете веб форму и получаете готовый сертификат. Второй вариант гораздо интереснее. Мы подпишем наш сертификат сами, ключом, на основе которого он был создан:

С помощью параметра -days мы указываем что сертификат будет действительным в течение 365 дней, то есть в течение года. Вы можете объединить все в одну команду и сразу создать закрытый ключ, csr и подписанный сертификат:

Или создаем самоподписанный сертификат openssl из существующего закрытого ключа без csr:

Опция -new говорит, что нужно запросить информацию о csr у пользователя. Чтобы браузер доверял ключу нужно этот же сертификат импортировать в список доверенных. А теперь рассмотрим третий способ выполнить создание сертификата OpenSSL — подписать его с помощью собственного CA, центра сертификации.

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

Вообще, центр сертификации в крупных корпорациях находится на отдельных компьютерах, которые даже к сети не подключены. Но для примера мы разместим папку в нашей файловой системе /etc/:

Дальше нужно создать самоподписанный сертификат openssl для нашего CA:

Параметр -extensions загружает необходимые расширения для создания сертификата центра сертификации. Мы устанавливаем долгий строк действия — десять лет. Осталось подписать наш сертификат, созданный ранее:

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

Configuration[edit]

Утилита командной строки curl

OpenSSL is configured for a particular platform with protocol and behavior options using Configure and config.

You should avoid custom build systems because they often miss details, like each architecture and platform has a unique opensslconf.h and bn.h generated by Configure.

Supported Platformsedit

You can run Configure LIST to see a list of available platforms.

$ ./Configure LIST
BC-32
BS2000-OSD
BSD-generic32
BSD-generic64
BSD-ia64
BSD-sparc64
BSD-sparcv8
BSD-x86
BSD-x86-elf
BSD-x86_64
Cygwin
Cygwin-x86_64
DJGPP
...

If your platform is not listed, then use a similar platform and tune the $cflags and $ldflags by making a copy of the configure line and giving it its own name. $cflags and $ldflags correspond to fields 2 and 6 in a configure line. An example of using a similar configure line is presented in .

Configure & Configedit

You use Configure and config to tune the compile and installation process through options and switches. The difference between is Configure properly handles the host-arch-compiler triplet, and config does not. config attempts to guess the triplet, so it’s a lot like autotool’s config.guess.

You can usually use config and it will do the right thing (from Ubuntu 13.04, x64):

$ ./config 
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring for linux-x86_64
    no-ec_nistp_64_gcc_128   OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
    no-gmp            OPENSSL_NO_GMP (skip dir)
    no-jpake         OPENSSL_NO_JPAKE (skip dir)
    no-krb5          OPENSSL_NO_KRB5
    ...

Mac OS X can have issues (it’s often a neglected platform), and you will have to use Configure:

 ./Configure darwin64-x86_64-cc
Configuring for darwin64-x86_64-cc
    no-ec_nistp_64_gcc_128   OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
    no-gmp            OPENSSL_NO_GMP (skip dir)
    no-jpake         OPENSSL_NO_JPAKE (skip dir)
    no-krb5          OPENSSL_NO_KRB5
    ...

You can also configure on Darwin by exporting KERNEL_BITS:

$ export KERNEL_BITS=64
$ ./config shared no-ssl2 no-ssl3 enable-ec_nistp_64_gcc_128 --openssldir=/usr/local/ssl/macosx-x64/
Operating system: i686-apple-darwinDarwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64
Configuring for darwin64-x86_64-cc
Configuring for darwin64-x86_64-cc
    no-gmp            OPENSSL_NO_GMP (skip dir)
    no-jpake         OPENSSL_NO_JPAKE (skip dir)
    no-krb5          OPENSSL_NO_KRB5
    ...

If you provide a option not known to configure or ask for help, then you get a brief help message:

$ ./Configure --help
Usage: Configure   
      threads] shared]
zlib|zlib-dynamic]      
 ]  os/compiler

And if you supply an unknown triplet:

$ ./Configure darwin64-x86_64-clang
Configuring for darwin64-x86_64-clang
Usage: Configure   
      threads] shared]
zlib|zlib-dynamic]      
 ]  os/compiler

pick os/compiler from:
BC-32 BS2000-OSD BSD-generic32 BSD-generic64 BSD-ia64 BSD-sparc64 BSD-sparcv8 
BSD-x86 BSD-x86-elf BSD-x86_64 Cygwin Cygwin-pre1.3 DJGPP MPE/iX-gcc OS2-EMX 
...

NOTE: If in doubt, on Unix-ish systems use './config'.

Dependenciesedit

If you are prompted to run make depend, then you must do so. For OpenSSL 1.0.2 and below, it’s required to update the standard distribution once configuration options change.

Since you've disabled or enabled at least one algorithm, you need to do
the following before building:

	make depend

OpenSSL 1.1.0 and above performs the dependency step for you, so you should not see the message. However, you should perform a make clean to ensure the list of objects files is accurate after a reconfiguration.

Создание промежуточного сертификата

Скачать windows 7 оригинальные образы 64 bit/32 bit iso

Используя промежуточный ключ создадим запрос на подписывание сертификата (CSR — certificate signing request). Сведения должны, как правило, соответствовать корневому центру сертификации. Общие имена (Common Name), однако, должны быть разными. И убедитесь, что используете конфигурационный файл промежуточного центра сертификаци ().

Чтобы создать промежуточный сертификат используем корневой центр сертификации с расширением для подписывания промежуточного запроса. Промежуточный сертификат должен быть действителен на меньший период, чем корневой. К примеру, на 10 лет. В этот раз следует использовать конфигурационный файл корневого центра сертификации ().

Для хранения базы данных сертификатов, выданных утилитой ca OpenSSL, используется файл index.txt. Не следует удалять или править вручную этот файл. Сейчас он должен содержать одну строку, которая относится к промежуточному сертификату.

Из исходника

Оформление реферата по гост 2019-2020

Устанавливаем пакеты, необходимые для сборки пакета:

yum install make gcc

* как видим, на момент написания обновления инструкции это была версия 1.1.1.

И копируем ссылку на ее скачивание:

На CentOS скачиваем исходник с использованием найденной ссылки:

wget https://www.openssl.org/source/openssl-1.1.1g.tar.gz

И распаковываем его с последующим удалением:

tar -xvf openssl-*.tar.gz && \rm openssl-*.tar.gz

Переходим в папку с распакованным исходником:

cd openssl-*

Конфигурируем его:

./config —prefix=/usr/local —openssldir=/usr/local

Собираем:

make

И устанавливаем:

make install

Резервируем предыдущую версию openssl:

mv /usr/bin/openssl /root/openssl.back

И делаем ссылку на новую:

ln -s /usr/local/bin/openssl /usr/bin/openssl

Снова проверяем версию:

openssl version -a

Система вернет либо ошибку, например:

openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

… либо полные сведения об openssl, например:

OpenSSL 1.1.1g 21 Apr 2020 (Library: OpenSSL 1.0.2k-fips 26 Jan 2017)
built on: Sat May 11 01:54:53 2019 UTC
platform: linux-x86_64
options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr)
compiler: gcc -fPIC -pthread -m64 -Wa,—noexecstack -Wall -O3 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wa,—noexecstack -Wa,—generate-missing-build-notes=yes -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM=»\»/dev/urandom\»» -DSYSTEM_CIPHERS_FILE=»/etc/crypto-policies/back-ends/openssl.config»
OPENSSLDIR: «/etc/pki/tls»
ENGINESDIR: «/usr/lib64/engines-1.1»
Seeding source: os-specific

Обратите внимание, что у нас установлена новая версия OpenSSL, но по прежнему, используется старая библиотека — Library: OpenSSL 1.0.2k-fips 26 Jan 2017. Необходимо добавить в ldconfig новый путь

Для это создаем файл:

Необходимо добавить в ldconfig новый путь. Для это создаем файл:

vi /etc/ld.so.conf.d/openssl.conf

/usr/local/lib64

* если у нас используется система 32-бит, то путь будет /usr/local/lib.

Применяем настройки:

ldconfig -v

Снова проверяем:

openssl version

Мы должны увидеть:

OpenSSL 1.1.1g 21 Apr 2020

Обновление выполнено.

Отзыв сертификата

Утилита OpenSSL ocsp может выступать в качестве ответчика OCSP, но она предназначена только для тестирования. Для производственной среды OCSP ответчики тоже существуют, но они выходят за рамки данной статьи.

Создадим серверный сертификат для тестирования.

Запустим ответчик OCSP на локальной машине. Вместо того, чтобы хранить статус отзыва в отдельном CRL файле ответчик OCSP напрямую читает файл index.txt. Ответ подписывается криптографической парой OCSP (используя опции –rkey и –rsigner).

В другом терминале пошлем запрос к OCSP ответчику. Опция указывает сертификат для запроса.

Начало вывода показывает следующее:

был ли получен положительный ответ (OCSP Response Status)
идентичность ответчика (Responder Id)
статус отзыва сертификата (Cert Status)

Отзыв сертификата.

Как и раньше, запускаем ответчик OCSP в другом терминале и шлем запрос. В этот раз вывод показывает и .

Express.js

const https = require("https");const fs = require("fs");const express = require("express");// прочитайте ключиconst key = fs.readFileSync("localhost.key");const cert = fs.readFileSync("localhost.crt");// создайте экспресс-приложениеconst app = express();// создайте HTTPS-серверconst server = https.createServer({ key, cert }, app);// добавьте тестовый роутapp.get("/", (req, res) => {  res.send("this is an secure server");});// запустите сервер на порту 8000server.listen(8000, () => {  console.log("listening on 8000");});

Как только вы настроите обслуживающий ваше приложение инструмент на работу с вашим сертификатом, ваше приложение будет доступно по URL’у с HTTPS.

Следуя приведенному выше примеру с Express, вы можете открыть вкладку браузера по адресу https://localhost:8000 и увидеть ваш контент:

Погодите секунду! Где же сообщение «это защищенный сервер»?

Вы рассчитывали увидеть кое-что другое, но именно этого и следовало ожидать — потому что источник сертификата еще не входит в число доверенных.

Доверие к сертификатам

Чтобы получить обозначение безопасного доступа, ваш новый источник сертификата должен считаться доверенным на вашей машине. Процесс присваивания этого статуса различается в зависимости от операционной системы и удовлетворит большинство браузеров. Если вы используете Firefox, процесс имеет некоторые отличия.

Special notes for Universal Windows Platform builds, aka VC-*-UWP

UWP targets only support building the static and dynamic libraries.
You should define the platform type to «uwp» and the target arch via
«vcvarsall.bat» before you compile. For example, if you want to build
«arm64» builds, you should run «vcvarsall.bat x86_arm64 uwp».

Native builds using Embarcadero C++Builder

Install Perl.
Open the RAD Studio Command Prompt.
Go to the root of the OpenSSL source directory and run:
perl Configure BC-32 —prefix=%CD%
make -N
make -N test
Build your program against this OpenSSL:
- Set your include search path to the «include» subdirectory of OpenSSL.
- Set your library search path to the OpenSSL source directory.

Note that this is very experimental. Support for 64-bit and other Configure
options is still pending.

Native builds using MinGW

MinGW offers an alternative way to build native OpenSSL, by cross compilation.

Usually the build is done on Windows in a GNU-like environment called MSYS2.

MSYS2 provides GNU tools, a Unix-like command prompt,
and a UNIX compatibility layer for applications.
However, in this context it is only used for building OpenSSL.
The resulting OpenSSL does not rely on MSYS2 to run and is fully native.

Requirement details
- Perl, at least version 5.10.0, which usually comes pre-installed with MSYS2
- make, installed using «pacman -S make» into the MSYS2 environment
- MinGW compiler: mingw-w64-i686-gcc and/or mingw-w64-x86_64-gcc.
  These compilers must be on your MSYS2 $PATH.
  A common error is to not have these on your $PATH.
  The MSYS2 version of gcc will not work correctly here.
In the MSYS2 shell do the configuration depending on the target architecture:

or
./Configure mingw64 …
or
./Configure …

for the default architecture.

Apart from that, follow the Unix / Linux instructions in INSTALL.md.
It is also possible to build mingw on Linux or Cygwin.

In this case configure with the corresponding —cross-compile-prefix= option.
For example

or
./Configure mingw64 —cross-compile-prefix=x86_64-w64-mingw32- …

This requires that you’ve installed the necessary add-on packages for
mingw cross compilation.

Linking native applications

This section applies to all native builds.

If you link with static OpenSSL libraries then you’re expected to
additionally link your application with WS2_32.LIB, GDI32.LIB,
ADVAPI32.LIB, CRYPT32.LIB and USER32.LIB. Those developing
non-interactive service applications might feel concerned about
linking with GDI32.LIB and USER32.LIB, as they are justly associated
with interactive desktop, which is not available to service
processes. The toolkit is designed to detect in which context it’s
currently executed, GUI, console app or service, and act accordingly,
namely whether or not to actually make GUI calls. Additionally those
who wish to /DELAYLOAD:GDI32.DLL and /DELAYLOAD:USER32.DLL and
actually keep them off service process should consider implementing
and exporting from .exe image in question own _OPENSSL_isservice not
relying on USER32.DLL. E.g., on Windows Vista and later you could:

If you link with OpenSSL .DLLs, then you’re expected to include into
your application code a small «shim» snippet, which provides
the glue between the OpenSSL BIO layer and your compiler run-time.
See also the OPENSSL_Applink manual page.

Hosted builds using Cygwin

Cygwin implements a POSIX/Unix runtime system (cygwin1.dll) on top of the
Windows subsystem and provides a Bash shell and GNU tools environment.
Consequently, a build of OpenSSL with Cygwin is virtually identical to the
Unix procedure.

To build OpenSSL using Cygwin, you need to:

Install Cygwin Perl, at least version 5.10.0
and ensure it is in the $PATH
Run the Cygwin Bash shell

Apart from that, follow the Unix / Linux instructions in INSTALL.md.

NOTE: «make test» and normal file operations may fail in directories
mounted as text (i.e. mount -t c:\somewhere /home) due to Cygwin
stripping of carriage returns. To avoid this ensure that a binary
mount is used, e.g. mount -b c:\somewhere /home.

Configuring OpenSSL

By default, OpenSSL on Windows 10 does not come with a configuration file. This is intentional because there are a lot of configuration options that you can customize. For the purposes of this guide, you are going to use a sample configuration that you can customize later to best suit your security requirements.

Open up PowerShell and run the below command. This command downloads a sample configuration file from MIT and saves it as openssl.cnf in the current working directory.

You can now open up the openssl.cnf file and you should see something that looks like below.

Sample OpenSSL configuration file

The downloaded configuration will work as-is for now. Do not use the defaults in a production environment!

Поддержка ГОСТ-сертификатов в nginx

Возможность работать из языков программирования это уже много, но хотелось еще две возможности:

Легко поднимать свой веб-сервер с ГОСТ-сертификатом по HTTPS (TLS).
Легко проксировать все запросы на хост с ГОСТ-сертификатом

Легко – это означает докер-образ. Его нужно создать. Для этого нужно в Dockerfile собрать nginx с кастомным OpenSSL и GOST-engine. Открыв документацию сборки nginx, я увидел одну опцию о ssl — , которая просто булева. Но nginx популярный продукт, инструкций по сборке с openssl много, поэтому я нашел еще опцию . Как показала практика, nginx хочет, чтобы здесь были исходники openssl, а сборкой скрипты nginx займутся сами. Это не совсем то, что я хотел бы (я хотел использовать multi-stage build). Я ознакомился с help-выводом сборщика nginx, но ничего, что мне там помогло бы, я не нашел.

Пришлось дублировать инструкции выкачивания исходников OpenSSL, распаковки, сборки GOST-engine, включения GOST-engine в конфиги. Всё это начало собираться, но поддержки ГОСТ-алгоритмов в nginx все ещё не было. Это я проверял указанием в конфиге . Выполнение говорило, что не знает этого алгоритма.

Как оказалось, openssl, собранный nginx, не поддерживал динамические движки, т.е. выводил . Здесь пришлось внимательно почитать документацию сборки OpenSSL, чтобы выяснить, что проставило . Причина нашлась в openssl, которые вызывал nginx, а именно . Если это указано, то нет никаких флагов, чтобы включить поддержку загрузки движков. Пришлось править инструкцию сборки:

Всё это собралось, но nginx начал ругаться, что не может найти по пути , это довольно странно, потому что тот же собранный openssl ищет и находит движки совсем в другом месте, а именно там, где и собирался . Добавил инструкцию копирования собранных движков в , чтобы угодить nginx. Заработало.

Рядом с основным Dockerfile в репозитории я положил демонстрационный Dockerfile, который при сборке создает себе ГОСТ-сертификаты и использует их, обрабатывая соединения на https://gost.example.com. Придется поработать с DNS или docker network, чтобы из одного контейнера попробовать подключится к этому демонстрационному, но все это я описал в документации.
Демонстрационный хост использует ключи по , другие варианты это , . А вместо — .
Образ с nginx + GOST запушен в Docker Hub: https://hub.docker.com/r/rnix/nginx-gost/

Поддержка ГОСТ-алгоритмов в PHP

PHP, конечно, позволяет делать вызовы системных команд, используя, например, . Но, глядя на то, как собирается PHP-FPM в Dockerfile, мне показалось, что можно легко собрать PHP с кастомными сборками OpenSSL и cURL. Как оказалось дальше, я ошибся, что это легко. Всё равно собрал.

По какой-то причине, я начал с PHP-FPM 7.1. Идея была в том, чтобы использовать multi-stage build. Для этого надо заменить в их Dockerfile инструкцию на мою , затем прописать копирования собранных openssl и curl до начала сборки самого php и, наконец, указать в опции сборки путь до этих библиотек и заменив оригинальные.

Сюрпризы ждали отовсюду. Одним из значительных было то, что при сборки php 7.1 используется pkg-config, а явная установка libcurl4-openssl-dev, libssl-dev прописывали в pkg-config версии из пакетов. В результате собиралось не то, что нужно. Если убрать их установку, то php падал, ссылаясь на отсутствие openssl в pkg-config. Пришлось дополнительно копировать из кастомных сборок openssl и curl их . После десятков таких сюрпризов сборка начала проходить. Дальше выяснилось, что зависимости устанавливали openssl, тем самым перезатирая ранее скопированный бинарник моей кастомной сборки. Пришлось дополнительно копировать его в самом конце. Но это не всё.

В собранном php появились алгоритмы хешей : , , . Это значило, что php подключил GOST-engine. А вот использование расширения curl в php почему-то говорило, что таких алгоритмов не знает, соединяясь с хостом по GOST-HTTPS. Я потратил несколько часов, пытаясь найти причину этого. Я смотрел исходники, как устроено расширение curl в php, как устроен сам curl, как они связываются с openssl. Я искал место, где могут определяться поддерживаемые алгоритмы или подключатся движки. Я искал по master-веткам, много гуглил, но ничего, что решило бы сразу проблему, не нашел. Тогда я вспомнил, что я собираю не последнюю версию PHP.

Я попробовал собрать PHP-FPM 7.2. Пришлось внести некоторые правки в мой скрипт корректировки оригинального Dockerfile PHP-FPM, но сборка начала проходить без большого количества сюрпризов. Главной новостью стало то, что теперь расширение curl внутри php умело общаться по ГОСТ-алгоритмам с хостами, но была одна неприятность. Каждый вызов php писал в stdout . Очень неприятно. Я не сразу понял, кто это делает, но нашел в исходниках GOST-engine. Я до сих пор не знаю, в какой части системы случилась ошибка: php, php-curl, curl, openssl. Но, видимо, в php 7.1 php-curl не подключал движок совсем, теперь в php 7.2 начал подключать его дважды. Так как все работало корректно, только был вывод, я решил его убрать правкой исходника инструкцией в Dockerfile:

Там строчкой ниже уже есть , поэтому ничего серьезного я не сделал. Зато, пересобрав весь зоопарк, все начало работать, как и хотелось.
Образ с PHP-FPM + OpenSSL + GOST + cURL запушен в Docker Hub.

Update PowerShell Profile Environment Variables

To make things go smoothly, you should modify your PowerShell profile on Windows 10. Setting up some environment variables allows you to easily switch between different versions of OpenSSL that you may have installed.

I suggest adding two environment variables to your PowerShell profile called and . You will update the environment variable to ensure you can run the openssl binary in any location while on the command line.

Below you’ll see a way to create a PowerShell profile if you don’t already have one. This command appends the OpenSSL binary path to your and assign the configuration file path to .

To use the environment variables, reload your profile typing or just close and reopen PowerShell.

Now you can easily invoke the openssl binary wherever you are in PowerShell as shown below.

Verifying OpenSSL version in PowerShell

Using OpenSSL on Windows 10 to Generate a CSR & Private Key

Before you can create an SSL certificate, you must generate a certifiate-signing request (CSR). A CSR is an encoded file that provides you with a way to share your public key with a certificate authority (CA). This file contains identifying information, a signature algorithm, and a digital signature. Let’s create your first CSR and private key.

Related: Your Guide to X509 Certificates for Mortals

To create a CSR, run the below command. OpenSSL will then prompt you to enter some identifying information as you can see in the following demonstration.

Generating a CSR and Private Key using OpenSSL in PowerShell

Once complete, you will have a valid CSR and private key which can be used to issue an SSL certificate to you.

The configuration file defaults can be edited further to streamline this process should you not want to enter data every time you generate a CSR.

Features and Technologies that Require OpenSSL

RAD Studio requires OpenSSL for HTTPS support for the following features and technologies:

Sending push notifications with the EMS Server: You need to install the OpenSSL libraries in the system where the RAD Server Engine (EMS Server) runs to send push notifications. You need to install the 32-bit or 64-bit OpenSSL depending on the EMS Server binary you are running.
Indy
InterBase: InterBase uses OpenSSL for encryption and OTW/SSL features.
DataSnap Server: OpenSSL is required by DataSnap servers when encryption filters are enabled, or when the Communication Protocol is set to HTTPS in the .

Firefox

Даже после того, как вы установите доверенный источник сертификата в хранилище, Firefox все равно будет выдавать предупреждения. Этого может не случиться в Windows 10, но почти наверняка случится в macOS. Справиться с этим достаточно просто. Firefox демонстрирует вот такой экран:

Чтобы добавить разрешения сертификату, кликните «Дополнительно…». Сразу же после этого кликните на «Принять риск и продолжить», чтобы дать понять, что вы знаете о риске.

Это нужно сделать всего один раз, но для каждого локального домена.

Заключение

Теперь, когда сертификат создан и доверие к нему обеспечено, вы без проблем можете посещать свой локальный домен! Обслуживание приложений стало безопасным, и вы можете спокойно продолжать разработку. Возвращаясь к примеру с Express, результат на экране будет таким:

Сайт полностью загружен, и рядом с URL в Chrome теперь отображается символ безопасного соединения.

Надеюсь, эта статья помогла вам превозмочь трудности с HTTPS.

Удачного программирования!

Как исправить ошибки сертификатов в Node-приложениях при работе с SSL
Как установить несколько версий Python в WSL2 и управлять ими
Работа с HTML и CSS: 10 полезных приемов для дизайнеров

Читайте нас в Telegram, VK и

Заключение

Мной изучена проблема работы с ГОСТ-алгоритмами в системах Linux, предоставлено решение в виде docker-образов, все это сопровождено документацией и примерами. Решение оформлено в виде репозитория на GitHub.

Стоит сказать о безопасности использования такого решения. Главное, не стоит доверять образам на Docker Hub, даже если там написано . Я все равно могу собрать образ с любыми правками всех используемых библиотек и систем и запушить его в свой Docker Hub под любым тегом. Поэтому рекомендую форкать репозиторий на гитхабе, пулить его себе и уже самостоятельно собирать, проверив инструкции в Dockerfile на наличие того, что используются только официальные ресурсы без подозрительных модификацией по ходу сборки.

Собирая образ самостоятельно, вы можете убедиться, что в код не попали злонамеренные правки, потому что сборка происходит только из открытого кода, который доступен для просмотра всем желающим. Тем не менее, это не гарантирует, что в нем нет ошибок и уязвимостей. Использование проприетарных сертифицированных средств так же не гарантирует отсутствие ошибок и уязвимостей, но к тому же их код от вас закрыт.