Ещё раз об OpenSSL / Хабр

Ecdsa

Чтобы создать закрытый ключ ECDSA с вашим CSR, вам необходимо вызвать вторую утилиту OpenSSL, чтобы сгенерировать параметры для ключа ECDSA.

Эта команда OpenSSL сгенерирует файл параметров для 256-битного ключа ECDSA:

openssl genpkey -genparam -algorithm ec -pkeyopt ec_paramgen_curve: P-256 -out ECPARAM.pem

Теперь укажите ваш файл параметров при создании CSR:

openssl req -newkey ec: ECPARAM.pem -keyout PRIVATEKEY.key -out МОЙCSR.csr

Команда такая же, как мы использовали в примере RSA выше, но -newkey RSA:2048 был заменен на -newkey ec:ECPARAM.pem, Как и прежде, вам будет предложено ввести пароль и информацию о различающемся имени для CSR.

При желании вы можете использовать перенаправление для объединения двух команд OpenSSL в одну строку, пропуская создание файла параметров, как показано ниже:

openssl req -newkey ec: <(openssl genpkey -genparam -algorithm ec -pkeyopt ec_paramgen_curve: P-256) -keyout PRIVATEKEY.key -out MYCSR.csr

Mac os x


Safari, FireFox, Chrome — используют системный репозиторий.

Запускаем KeyChain Access.Идём в меню File — Import Items (login или System) — выбираем файл rootCA.crt.Когда нас спросят, отвечаем — Always Trust.

Для вашего личного Safari достаточно выбрать login.

Rutoken, openssl и локальный уц для подписи сообщений

Настраиваем «наш» openssl.cnf:

а) Добавляем в начало файла директивы для подключения движка токена:

openssl_conf = openssl_def
[ openssl_def ]
engines = engine_section

[ engine_section ]
rtengine = gost_section

[ gost_section ]
dynamic_path = /path/to/rutoken/openssl/connector/librtengine.so
MODULE_PATH = /path/to/rutoken/pkcs11/librtpkcs11ecp.so
RAND_TOKEN = pkcs11:manufacturer=Aktiv Co.;model=Rutoken ECP
default_algorithms = CIPHERS, DIGEST, PKEY, RAND


б) раскомментируйте строку

# req_extensions = v3_req # The extensions to add to a certificate request


в) в секции [ v3_req ] укажите следующие параметры:

subjectSignTool = ASN1:FORMAT:UTF8,UTF8String:Наш Рутокен ЭЦП
extendedKeyUsage=emailProtection
keyUsage=digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment


г) в секции [ v3_ca ] надо убрать опцию critical из параметра basicConstraints:

basicConstraints = CA:true

Для чего? Честный ответ: не знаю. Однако все примеры корневых сертификатов, которые я скачивал в процессе попыток разобраться в теме, были без признака critical. Адресую вопрос «для чего?» более опытным в вопросе коллегам.

д) опционально устанавливаем значения по умолчанию, которые будут предлагаться при выпуске самоподписанных сертификатов и генерации запросов на выпуск клиентских сертификатов. Эти параметры находятся в секции [ req_distinguished_name ]

Параметр с постфиксом _default — то самое значение по умолчанию. Пример:

countryName			= Country Name (2 letter code)
countryName_default		= AU
countryName_min		= 2
countryName_max		= 2


Когда система попросит ввести параметр countryName, то в квадратных скобочках укажет, что по умолчанию оставит значение AU.

На этом настройка конфига OpenSSL завершена. Осталось указать OpenSSL, что использовать надо именно его. Для этого устанавливаем переменную окружения OPENSSL_CONF:

export OPENSSL_CONF=/path/to/your/openssl.cnf

Опционально форматируем наш токен, используя утилиту rtAdminТеперь все готово к развертыванию УЦ.

Алгоритм действий в общих чертах прост:

а) выпускаем корневой сертификат удостоверяющего центра, используя алгоритм ГОСТ:

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

б) на каждом из USB-токенов

  • генерируем ключевую пару (т.н. контейнер закрытого ключа)
  • генерируем запрос на подпись сертификата, используя сгенерированный ключ токена
  • выпускаем сертификат по этому запросу
  • сохраняем сертификат на токене в контейнере закрытого ключа

Ниже приведена реализация этого алгоритма для одного токена:

Генерация закрытого ключа для сертификата CA (используем алгоритм ГОСТ):

openssl genpkey -algorithm gost2021_256 -pkeyopt paramset:A -outform PEM -out demoCA/private/cakey.pem


Выпускаем самоподписанный сертификат CA:

<b>openssl req -new -x509 -key demoCA/private/cakey.pem -out demoCA/certs/cacert.pem -extensions v3_ca -days  3650 -outform PEM 

Обратите внимание: мы указали в командной строке, что необходимо использовать расширения v3_ca из конфига openssl_cnf. Именно там прописано, что это наш CA. Срок действия 10 лет. Обычное дело для CA. Но можно и больше.

В процессе выпуска сертификата система попросит ввести значения параметров, которые находятся в секции [ req_distinguished_name ] нашего файла openssl.cnf

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

Первым делом сгенерируем ключевую пару. OpenSSL не умеет выполнять эту операцию на Рутокене, поэтому воспользуемся утилитой pkcs11-tool из пакета OpenSC:

pkcs11-tool --module /path/to/your/librtpkcs11ecp.so --login --pin 12345678 --keypairgen  --key-type GOSTR3410:A --id 303030303031 --label 'client01'


Важное замечание: мы указали id 303030303031. Каждые две цифры этого id ни что иное как ASCII-код символов «0» и «1» соответственно. При операциях с OpenSSL это будет выглядеть как «id=000001»

Генерируем запрос на сертификат:

openssl req -utf8 -new -keyform engine -key 'pkcs11:id=000001' -engine rtengine -out demoCA/newcerts/client01.csr


Если все было сделано верно, то система

  • запросит PIN
  • запросит параметры имени сертификата (из секции [ req_distinguished_name ])
  • выпустит файл запроса на подпись сертификата
Читайте также:  Выписка из ЕГРЮЛ/ЕГРИП онлайн за 1 минуту.

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

openssl ca -utf8 -days  1825 -keyfile demoCA/private/cakey.pem -cert demoCA/certs/cacert.pem -in demoCA/newcerts/client01.csr -outdir demoCA/newcerts -out demoCA/certs/client01.pem


Система отобразит сертификат, спросит о решении подписать его (отвечаем «y»), и о решении сохранить новый сертификат (снова отвечаем «y»).

Сохраняем полученный сертификат на токен:

pkcs11-tool --module /path/to/your/librtpkcs11ecp.so --login --pin 12345678 --id=303030303031 -w demoCA/certs/client01.pem -y cert


Все.

Тестируем созданное «чудо». Для этого подписываем и проверяем подпись фразы «Hello, world!»:

echo Hello,world! | openssl cms -nodetach -sign -signer demoCA/certs/client01.pem -keyform engine -inkey "pkcs11:id=000001" -engine rtengine -binary -noattr -outform PEM | openssl cms -verify -CAfile demoCA/certs/cacert.pem -inform PEM


Если все сделано верно, то система запросит PIN, подпишет сообщение, затем проверит подпись и в случае успеха выведет на экран исходное сообщение и результат проверки («успех»)

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

Успехов!

Windows


IE, Chrome — используют репозиторий сертификатов Windows.

Мой путь к нему таков:

Chrome — Settings — Manage Certificates…Выбрать таб Trusted Root Certificate Authorities — Import — rootCA.crtперезапустить Chrome

FireFox на виндоус имеет свой репозиторий.

Java имеет свой репозиторий.

В ubuntu

sudo mkdir /usr/share/ca-certificates/extra
sudo cp rootCA.crt /usr/share/ca-certificates/extra/rootCA.crt
sudo dpkg-reconfigure ca-certificates
sudo update-ca-certificates

Видео

В этих инструкциях мы собираемся использовать OpenSSL req утилита для генерации как закрытого ключа, так и CSR в одной команде. Генерация секретного ключа таким способом гарантирует, что вам будет предложено ввести пароль для защиты закрытого ключа.

Во всех приведенных примерах команд замените имена файлов, показанные в ALL CAPS, на фактические пути и имена файлов, которые вы хотите использовать. (Например, вы можете заменить PRIVATEKEY.key с /private/etc/apache2/server.key в среде MacOS Apache.) Это практическое руководство охватывает генерацию обоих RSA и ECDSA ключи.

Ещё раз об openssl

В моей ещё небольшой практике в сфере информационной безопасности мне пришлось столкнуться с некоторыми вопросами криптографии, а точнее шифрования, внятные ответы на которые мне удалось найти с трудом. Потому решил написать небольшую статью по основам работы с OpenSSL.

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

Начнем. На самом деле пока все просто.

Создадим приватный ключ командой.

openssl genrsa -out key.pem -aes-256-cfb -rand /var/log/messages 4096

Ещё раз об OpenSSL / Хабр

Здесь:

genrsa — парметр указывающий на создание ключа алгоритмом шифрования RSA.
out — где создать ключ.
4096 — длина ключа.
Вообще этого для создания ключа достаточно. Но приватный ключ лучше зашифровать.
aes-256-cfb — алгоритм и режим шифрования.
rand /var/log/messages — рандомное значения из любой папки, лучше взять логи, т.к. с /dev/random или /dev/urandom может все повиснуть наглухо, у меня так и было.
При создании ключа будет запрошен пароль. Пароль — это основа любой защиты, так что постарайтесь покорпеть над ним. И запомнить.

Имеем ключ. Приватный. Никому никогда не показывать и спрятать по принципу Кощея Бессмертного.

На его основе сделаем публичный, который можно хоть на всеобщее обозрение выложить, хоть на лоб приклеить.

openssl rsa -in privatkey.pem -pubout -out publickey.pem

Ещё раз об OpenSSL / Хабр

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

Задача шифрования большого файла имеет другое решение.

Для шифрования большого количества данных используем, например, этот файл pdf размером 1,8 Mbytes.

Ещё раз об OpenSSL / Хабр

Большой объем данных шифруется симметричным алгоритмом шифрования, например, AES. Здесь мы применим и асимметричное шифрование для передачи симметричного ключа, с помощью которого мы и будем шифровать текст.

Начнем.

Создадим симметричный сессионный (одноразовый) ключ рандомной последовательностью символов и запишем в файл в представлении base64.

openssl rand -base64 32 > key.bin

Далее зашифруем файл этим ключом:

openssl enc -aes-256-cfb -salt -in OWASP_Top_10-2021_(en).pdf -out OWASP_Top_10-2021_(en).pdf.enc -pass file:./key.bin

Ещё раз об OpenSSL / Хабр

aes-256-cfb — алгоритм и режим шифрования. О режимах здесь не буду говорить. Этот лучший.
salt — соль для большей криптостойкости.
pass file:./key.bin — ключ шифрования.

Далее зашифруем симметричный ключ нашим публичным «ассиметричным» ключом.

openssl rsautl -encrypt -inkey publickey.pem -pubin -in key.bin -out key.bin.enc

Ещё раз об OpenSSL / Хабр

Получили зашифрованный файл и симметричный ключ. Можно слать своему товарищу для расшифровки. Но мы пошлем сами себе, ибо это homework c самим с собой.

Читайте также:  Справку о том, что физическое лицо не является индивидуальным предпринимателем, можно получить бесплатно | ФНС России | 72 Тюменская область

Теперь удалим изначальный симметричный ключ! Чтобы никто и никогда не нашел его.

shred -u key.bin

На картинке внизу его уже нет.

Ещё раз об OpenSSL / Хабр

Теперь расшифруем симметричный ключ нашим приватным ассиметричным ключом.

openssl rsautl -decrypt -inkey privatkey.pem -in key.bin.enc -out key.bin

И мы, счастливчики, снова имеем симметричный ключ для расшифрования нашего текста, пока еще зашифрованного.

Картинка снова внизу, там ключ вновь есть.

Ещё раз об OpenSSL / Хабр

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

openssl enc -d -aes-256-cfb -in OWASP_Top_10-2021_(en).pdf.enc -out OWASP_Top_10-2021_(en)decrypt.pdf -pass file:./key.bin

Пруф внизу.

Ещё раз об OpenSSL / Хабр

Теперь: Почему так сложно? Почему нельзя взять и сделать все с помощью ассиметричного шифрования?

Пробуем, идем прямиком на грабли;)
Имеем!

Файл и ключи.

Ещё раз об OpenSSL / Хабр

Шифруем.

openssl rsautl -encrypt -inkey publickey.pem -pubin -in OWASP_Top_10-2021_(en).pdf -out OWASP_Top_10-2021_(en).pdf.enc

Поу — поу — поооооууууу. Ошибка. Слишком много данных для размера ключа. Ибо в ассиметричном шифровании размер ключа должен быть больше или равен открытому тексту.

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

Ещё раз об OpenSSL / Хабр

Но можно зашифровать меньший, чем ключ файл. Попробуем.

Создадим небольшой файл.

Например, я сделал так:

echo "hellow world my name is admin is a secret text nobody know it hahahahaahah" > text.txt

Ещё раз об OpenSSL / Хабр

Зашифруем его нашим публичным ключом, который знают все на свете!

openssl rsautl -encrypt -inkey publickey.pem -pubin -in text.txt -out text.txt.enc

Как видим на нижней картинке файл зашифрован. Ничего не понятно! Кому понятно, КТО ВЫ?

Ещё раз об OpenSSL / Хабр

Теперь расшифруем, предварительно удалив для чистоты эксперимента исходный файл.

openssl rsautl -decrypt -inkey privatkey.pem -in text.txt.enc -out text.txt

Ещё раз об OpenSSL / Хабр

Имеем расшифрованный файл. Все отлично.

Для передачи всего этого зашифрованного добра лучше последнее кодировать в base64. Соответственно перед тем как расшифровать, нужно сначала раскодировать.
Закодировали.

openssl enc -base64 -in text.txt.enc -out text.txt.bs64

Ещё раз об OpenSSL / Хабр

Раскодировали.

openssl enc -base64 -d -in text.txt.bs64 -out text.txt.enc

Ещё раз об OpenSSL / Хабр

И снова имеем белеберду, которая никому не понятна! Если Вам понятна, то этот документ не для Вас!

Примерно так работает шифрование при создании ключей и шифрованиие данных на примере утилиты OpenSSL.

Позже собираюсь описать режимы шифрования блочных симметричных шифров.

Как проверяется доверие на практике?

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

В Windows сертификаты можно просмотреть через оснастку certmgr.msc:

Если поместить сертификат в хранилище «Доверенные корневые центры сертификации», то такому центру система будет доверять. А поскольку это хранилище корневых центров сертификации, система потом будет доверять и всем объектам, которые подписаны этим сертификатом.

В ОС Ubuntu Linux сертификаты хранятся в каталоге /etc/ssl/cetrs. Причём часть из них — ссылки на другой объект:

Настройка apache 2 для использования сертификатов

Переходим в каталог /etc/apache2:

root@shpc:/mnt# cd/etc/apache2/

Создаём каталог для хранения сертификатов:

root@shpc:/etc/apache2# mkdir ssl

Включаем модуль SSL для веб-сервера. Тестирование проводилось на ОС Ubuntu Linux, поэтому модуль достаточно просто включить:

a2enmod headers

Перезапускаем веб-сервер:

root@shpc:/etc/apache2# systemctl restart apache2

Аналогично нужно включить поддержку заголовков: 

Теперь создадим конфигурационный файл для модуля SSL. Пример содержимого для него можно взять на Syslink.pl. Команды такие:

root@shpc:/mnt# cd /etc/apache2/conf-available
root@shpc:/etc/apache2/conf-available# nano ssl-params.conf

Сам файл будет содержать следующие параметры (чтобы было проще работать, мы отключили заголовки Strict-Transport-Securrity, X-Frame-Options и X-Content-Type-Options):

Далее созданный конфиг надо активировать:

root@shpc:/etc/apache2/conf-available# a2enconf ssl-params

Теперь переходим в каталог /etc/apache2/sites-available:

root@shpc:/etc/apache2/conf-available# cd/etc/apache2/sites-available

И делаем на всякий случай резервные копии всех хранящихся там файлов:

root@shpc:/etc/apache2/sites-available# cp 000-default.conf 000-default.conf.bak
root@shpc:/etc/apache2/sites-available# cp default-ssl.conf default-ssl.conf.bak

Теперь ещё раз проверяем подключённые модули headers и SSL:

Далее нам надо перенести созданные сертификаты (сертификат CA и сертификат сервера) в каталог /etc/ssl/certs, а ключ сертификата сервера — в каталог /etc/ssl/private:

root@shpc:/opt/simple_CA# cp ca.cer /etc/ssl/certs/
root@shpc:/opt/simple_CA# cp server.cer /etc/ssl/certs/server.crt
root@shpc:/opt/simple_CA# cp server.key /etc/ssl/private/server.key

Далее откроем конфиг сайта (/etc/apache2/sites-available/000-default-ssl.conf) и добавим туда следующие опции:

SSLCertificateFile /etc/ssl/certs/server.crt
SSLCertificateKeyFile /etc/ssl/private/server.key
SSLCACertificateFile /etc/ssl/certs/ca.cer

Теперь перезагружаем веб-сервер:

root@shpc:/etc/apache2# a2ensite default-ssl
root@shpc:/etc/apache2/sites-available# service apache2 restart

Проверяем доступность сайта:

Видим, что Firefox не может проверить сертификат сайта. Чтобы смог, надо импортировать цепочку сертификатов, подтверждающих сертификат сервера, в список доверенных. Создадим цепочку:

root@shpc:/opt/simple_CA# openssl crl2pkcs7 -nocrl-certfile ca.cer -certfile server.cer -out serve-and-ca-chain.p7c -outform der

У полученного файла не забываем сменить атрибуты на 555:

root@shpc:/opt/simple_CA# chmod555 serve-and-ca-chain.p7c 

Теперь откроем в браузере менеджер сертификатов и импортируем полученную цепочку (кнопка Import):

Читайте также:  КриптоПро | О компании

Далее можно просмотреть сертификаты и настроить доверие — вдруг что-то упущено:

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

Сейчас время настроить аутентификацию для клиентов. 

Настройка аутентификации клиентов

Веб-сервер Apache поддерживает аутентификацию клиента. Это значит, что мы можем выписать клиенту сертификат SSL, а сервер сможет его проверить. Если у пользователя не будет сертификата — аутентификация не пройдёт. Для активации такой возможности надо добавить в конфиг default-ssl.conf такие опции:

SSLCACertificateFile /opt/simple_CA/ca.cer 
SSLVerifyClient require 
SSLVerifyDepth 2

После этого к сайту сможет подключиться только тот пользователь, сертификат которого:

  • установлен в браузере, если клиентом является браузер, — тогда сертификат будет предъявлен при подключении к серверу;
  • подписан сертификатом доверенного УЦ.

Сначала сгенерируем сертификат для клиента. Первым делом создаём ключ:

root@shpc:/opt/simple_CA# openssl genrsa -out client.key 4096

Затем на основе ключа сгенерируем CSR:

root@shpc:/opt/simple_CA# openssl req -new-key client.key -out client.req

Теперь на базе запроса сгенерируем сам сертификат:

root@shpc:/opt/simple_CA# openssl req -new-key client.key -out client.req

И импортируем сертификат в формате p12:

root@shpc:/opt/simple_CA# openssl pkcs12 -export-inkey client.key -in client.cer -out client.p12 

В итоге у нас должен получиться файл client.p12. Нужно поменять права на файл, иначе сертификат не импортируется:

root@shpc:/opt/simple_CA# chmod555 client.p12

Теперь можно импортировать его в браузер по аналогии с корневыми сертификатами:

После импорта должно получиться примерно так:

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

Программа сервера на go

Программа сервера на Go myserver.go, которая использует наш подписаный сертификат.

Разворачиваем собственный цс

Чтобы лучше понять все процессы, лежащие в основе PKI, рассмотрим на практике развёртывание небольшого ЦС на виртуальной машине под управлением Ubuntu 18 (без выхода в глобальную сеть). Мы не будем жёстко придерживаться правил и стандартов выдачи сертификатов — просто разберём работу с ними.

С учетом того, что. все эксперименты мы проводим в виртуальной среде (без выхода в глобальную сеть), мы можем использовать любое доменное имя — например www.simple.org. Однако надо помнить, что в глобальной сети такое имя вполне может быть зарегистрировано за каким-нибудь сайтом.

Создаем наше ca


Первая команда создаёт корневой ключ

openssl genrsa -out rootCA.key 2048

Для меня ключ 2048 bit достаточен, если вам хочется, вы можете использовать ключ 4096 bit.

Вторая команда создаёт корневой сертификат.

openssl req -x509 -new -key rootCA.key -days 10000 -out rootCA.crt

Отвечать на вопросы тут можно как душе угодно.

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

10000 дней срок его годности, примерно столько живет сертификат, которым google требует подписывать андроид приложения для Google Play. Если вы паникер, подписывайте на год или два.

Все! Теперь мы можем создавать сертификаты для наших серверов и устанавливать корневой сертификат на наши клиентские машины.

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

Генерируем ключ.

openssl genrsa -out server101.mycloud.key 2048

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

openssl req -new -key server101.mycloud.key -out server101.mycloud.csr


Тут важно указать имя сервера: домен или IP (например домен

server101.mycloud

Common Name (eg, YOUR name) []: server101.mycloud

и подписать запрос на сертификат нашим корневым сертификатом.

openssl x509 -req -in server101.mycloud.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out server101.mycloud.crt -days 5000

Теперь на клиенты нужно установить корневой сертификат rootCA.crt

rootCA.crt — можно давать друзьям, устанавливать, копировать не сервера, выкладывать в публичный доступrootCA.key — следует держать в тайне

Центры сертификации: как они используются

Задача центра сертификации — подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи. Логику работы ЦС, как правило, можно описать тезисом «никто не доверяет друг другу, но все доверяют ЦС».

Допустим, условная сущность Аlice имеет сертификат, подписанный ЦС Comp, а сущность Bob пытается проверить подлинность этого сертификата. Проверка будет успешной, если Bob и Alice доверяют одному и тому же ЦС. Для решения такой проблемы в ОС Alice и ОС Bob установлено множество сертификатов различных ЦС.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector