Имя и альтернативные имена субъекта сертификата не соответствуют доменному имени узла

  curl -X GET --header 'Accept: application/json' --header 'Authorization: Bearer 90d2c018-73d1-324b-b121-a162cf870ac0' 'https://172.17.0.1:8243/V1.0.2/stock/getNA?name=te'

«curl: (51) SSL: имя субъекта сертификата (localhost) не соответствует целевому имени хоста «172.17.0.1»»

Однако после того, как я изменил «172.17.0.1» на «localhost», это сработало, и я получил результат.

Почему? Где-то неправильная конфигурация? При этом в файле http_access.log нет никакой информации журнала.

Ошибка сертификата. Существуют проблемы с цепочкой сертификатов сайта (net :: ERR_CERT_COMMON_NAME_INVALID).

Как я могу это исправить?

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

Ранее мы писали о базовых правилах безопасности сайта и важности перехода на HTTPS. В этой статье мы расскажем о настройке SSL-/TLS-сертификата и типичных ошибках, которые могут навредить сайту.

SSL (Secure Sockets Layer) и TLS (Transport Layer Security) — стандартизированная технология шифрования, которая защищает передаваемые сайтом и сайту данные. Она напрямую связана с HTTPS (Hypertext Transfer Protocol Secure): если сайт использует HTTPS-подключение, это значит, что данные передаются по протоколу SSL или TLS.

SSL была представлена в 1995 году и обновлена до TLS в 1999-м — технология видоизменялась, реагируя на новые уязвимости. Протоколы постоянно обновляются и большинство их предыдущих версий считаются устаревшими. Важно следить за обновлениями и использовать самую актуальную версию SSL/TLS.

Как SSL/TLS влияет на продвижение

Для Google безопасность всегда среди главных приоритетов: поисковик учитывает наличие HTTPS при ранжировании с 2014 года и постоянно обновляет требования к SSL-/TLS-сертификатам.

Большинство браузеров маркируют незащищенные страницы — проверить безопасность соединения можно по значку замка в адресной строке. Safari показывает этот значок, только если сайт использует адекватное шифрование; Firefox показывает перечеркнутый замок при недостаточном уровне защиты на сайтах, которые используют пользовательские данные; Chrome показывает красный треугольник при проблемах с безопасностью и значок замка при безопасном соединении.

Хоть преимущества технологии SSL/TLS довольно очевидны, многие сайты до сих пор не перешли на HTTPS или же используют недостаточно надежные версии протоколов. Статистика 2019 года говорит о том, что 20% крупнейших сайтов в мире не используют безопасный протокол, а по данным на начало 2020 года, только 18% доменных имен в зоне .ru используют узлы HTTPS.

Многие владельцы сайтов не хотят заморачиваться с покупкой и обновлением SSL-/TLS-сертификата или считают, что он им не нужен, если ресурс не собирает пользовательские данные. Но в современных реалиях ваш сайт будет попросту терять клиентов и позиции в поиске, если вы не перейдете на HTTPS и не будете следить за актуальностью шифрования. Для вашего удобства существует множество инструментов для настройки и мониторинга SSL-/TLS-сертификатов, в том числе бесплатные, как Let’s Encrypt.

Как исправлять типичные ошибки SSL/TLS

Если у вас уже есть SSL-/TLS-сертификат, он требует регулярного обновления и мониторинга. Чтобы избежать ошибок, проверяйте свой сайт на наличие проблем с SSL/TLS. Вы можете быстро обнаружить возможные ошибки с помощью «Аудита сайта» SE Ranking — для этого перейдите в раздел «Отчет об ошибках» и секцию «Безопасность сайта»:

Давайте рассмотрим 4 частые ошибки SSL-/TLS-сертификатов и объясним, как их исправить.

1. Недействительный сертификат

У сертификата безопасности есть определенный срок действия. Он постоянно уменьшался: до 5 лет в 2011-м, до 3 лет в 2015-м, до 2 лет в 2018-м. Сейчас сертификаты действительны только 398 дней (13 месяцев) — с 2020 года Safari, Chrome и Mozilla прекратили поддержку сертификатов с большим сроком действия.

Информация о дате истечения действия сертификата доступна в браузере:

Что же происходит, если SSL-/TLS-сертификат устаревает? Сайт становится недоступен — пользователи увидят сообщение о небезопасности в браузере. Результат — существенные потери трафика и, соответственно, прибыли.

Поэтому стоит знать дату истечения действия сертификата и вовремя его обновлять. Помогут вам в этом автоматизированные решения типа Let’s Encrypt, AWS Certificate Manager. Также существуют инструменты, которые несколько раз оповещают вас перед окончанием срока действия сертификата. Иногда и вовсе ничего делать не нужно, ведь многие центры сертификации предлагают автоматическое обновление. 

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

• Выбрать тип сертификата. Большинство центров сертификации предлагает несколько вариантов, покрывающих потребности сайтов разного масштаба. Если вы только обновляете существующий сертификат и не хотите поменять его тип, этот шаг у вас уже выполнен (иногда логично переключиться на более мощный тип сертификата — например, приобрести Wildcard-сертификат, если у вашего сайта появились поддомены). Покупая новый сертификат, внимательно проверяйте авторитетность производителя. Вы можете настроить CAA-запись, чтобы ограничить круг удостоверяющих центров, имеющих право выпускать сертификаты для вашего домена. Среди самых популярных центров сертификации — GlobalSign, Digicert, Sectigo, Thawte.
• Сгенерировать запрос на получение сертификата. После покупки нужно сгенерировать CSR (certificate signing request) у хостинг-провайдера. В результате вы получите файл ключа и сам запрос для загрузки в настройках сертификата.
• Активировать и валидировать сертификат. Далее нужно подтвердить свои права на домен через email, CNAME-запись или подтверждающий файл. Как и в предыдущем процессе, особенности настройки зависят от выбранного провайдера.
• Проверить корректность работы сертификата. После установки сертификата проверьте его с помощью онлайн-инструмента. Например:

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

2. Устаревшая версия протокола безопасности

Технологии шифрования совершенствуются, но и хакерские атаки становятся все изощреннее. Постоянно растущие риски — одна из причин сокращения срока действия SSL-/TLS-сертификатов и обновления протокола.

Читать также:  Сертификат соответствия на уайт спирит скачать бесплатно pdf

Протокол TLS был представлен как апгрейд SSL (версии 3.0 на тот момент), поэтому любая версия TLS более безопасна чем SSL. Самый актуальный протокол — TLS 1.3, выпущенный в 2018 году, — имеет усовершенствованный криптографический алгоритм и позволяет браузеру быстрее подсоединиться к серверу сайта. С 2020 года все основные браузеры не поддерживают устаревшие версии TLS (1.0 и 1.1), а значит не пускают пользователей на сайты, использующие эти версии.

Важно использовать актуальную версию протокола безопасности и отключать все предыдущие версии. Существует несколько способов проверить, какой протокол у сайта:

• Во вкладке Security в Chrome DevTools:

• В онлайн-инструментах, проверяющих, какие версии TLS и SSL включены на сайте. Например:

Чтобы включить последнюю версию TLS, прежде всего убедитесь, что ваш сайт поддерживает ее. Запустите серверную проверку — например, в SSL Labs — и просмотрите результаты конфигурации:

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

Скажем, ваш сайт размещен на сервере Nginx. Вам нужно отредактировать файл nginx.conf, указав в нем установленную версию TLS. Также удалите из файла все ранее используемые версии, которые признаны устаревшими. Строка конфигурации будет выглядеть так:

ssl_protocols TLSv1.2 TLSv1.3;

Если же окажется, что ваш сайт не поддерживает TLS 1.2 или 1.3, стоит обратиться к провайдеру и по возможности сменить тариф (или провайдера). 

3. Несоответствие имени сертификата

Ошибка неверного имени сертификата вызвана тем, что доменное имя, указанное в SSL-/TLS-сертификате, не соответствует введенному в адресной строке. Пользователи в таком случае не смогут зайти на сайт.

Причины несоответствия имени SSL-/TLS-сертификата:

• На сайт заходят через внутреннее доменное имя, не указанное в сертификате. Например, вы вводите в адресную строку vashsajt.localhost, тогда как ваш сертификат содержит только vashsajt.com. Вы можете решить эту проблему с помощью сертификата с альтернативным именем субъекта SAN — такой тип позволяет включать целый ряд имен хостов. Проверяйте наличие сертификатов SAN у разных удостоверяющих центров.
• Сайт доступен и с префиксом www, и без, тогда как в сертификате указана только одна версия. Вам нужно решить, хотите ли вы использовать www в доменном имени, перенаправить весь трафик сайта на соответствующую версию и указать ее в SSL-/TLS-сертификате. Мы детальнее разбираем этот вопрос в статье о префиксе www и его влиянии на SEO.
• Сайт делит IP-адрес с другими и не имеет отдельного протокола. Для большинства сайтов необязателен отдельный IP-адрес, а использование совместного экономит бюджет. Если у вашего сайта общий IP, укажите доменное имя в расширении протокола SNI. С помощью SNI сервер будет выбирать уникальный для вашего имени хоста TLS-сертификат и соответствующий ключ. Без такого расширения сервер будет использовать шаблонный сертификат, общий для нескольких сайтов, и он может быть слабее установленного вами протокола.
• Хостинг-провайдер сайта использует шаблонные настройки, которые предопределяют SSL/TLS для доменного имени. Чтобы решить эту проблему, нужно связаться с провайдером и узнать, как заменить их сертификат на ваш, или же поменять провайдера.

В онлайн-инструментах можно проверить, какие доменные имена включены в ваш SSL-/TLS-сертификат:

4. Устаревший алгоритм шифрования

Когда пользователь заходит на сайт, происходит процесс «рукопожатия»: клиент (браузер) и сервер идентифицируют друг друга, браузер при этом проверяет подлинность SSL-/TLS-сертификата. Набор алгоритмов шифрования очень важен для этого процесса: браузер сообщает, какие комбинации шифров он поддерживает, и сервер выбирает лучшую из подходящих. Если набор алгоритмов шифрования, используемый в конкретном сертификате, недостаточно надежный, браузер выдаст предупреждение об устаревшей криптографии.

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

• Алгоритм для обмена ключами между сервером и браузером (ECDHE)
• Цифровая подпись, удостоверяющая сертификат (ECDSA)
• Шифр для обмена данными (AES-256-GCM)
• Алгоритм для аутентификации сообщений (SHA384)

Комбинация в TLS 1.3 содержит только два последних шифра и по умолчанию не поддерживает устаревшие алгоритмы для обмена ключами и аутентификации сертификата.

Версия TLS 1.2 до сих пор считается достаточно надежной, но у нее есть уязвимости из-за большей вариативности алгоритмов шифрования и их качества. С TLS 1.3 выбор шифров ограничен самыми безопасными и весь процесс «рукопожатия» происходит проще и быстрее.

Если вы не знаете, какие шифры поддерживаются вашим сертификатом, стоит проверить их актуальность. Можно запустить онлайн-тест:

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

Обеспечьте сайту бескомпромиссную защиту

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

Анастасия — контент-маркетолог и редактор в SE Ranking, пишет про SEO, маркетинг и цифровые технологии. Кроме текстов для блога SE Ranking, Анастасия пишет музыку, а также любит старые фильмы и свою собаку.

5 ответов

CN сертификата WSO2 по умолчанию: localhost. Поэтому вы должны использовать localhost в качестве имени хоста при отправке запросов. В противном случае проверка имени хоста завершается ошибкой.

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

18 Май 2021 в 20:02

У меня действительно была эта проблема, и я нашел решение:

Я запрашивал URI типа «http://some.example», но для переменной HTTPS было установлено значение «1».

18 Май 2021 в 20:04

Подробнее см .:

12 ответов

Начиная с версии 0.9.2 (включая 0.10.x) node.js теперь проверяет сертификаты по умолчанию. Вот почему вы можете увидеть, что он стал более строгим при обновлении до версии Node.js 0.8. (HT: https://github.com/mscdex/node-imap/ issues / 181 # issuecomment-14781480)

Было бы лучше сначала диагностировать, почему сертификат не авторизует, и посмотреть, можно ли это исправить.

1 Май 2013 в 04:41

Слегка обновленный ответ (так как я столкнулся с этой проблемой при разных обстоятельствах.)

Установка флага rejectUnauthorized в значение false позволит обойти эту проверку, но, во-первых, если сервер предоставляет вам учетные данные, отличные от ожидаемых, происходит что-то подозрительное, а во-вторых, это также обойдет другие проверки — это не так. хорошая идея, если вы подключаетесь через Интернет.

Если вы используете node> = 0.11.x, вы также можете указать checkServerIdentity: function(host, cert) в модуль tls, который должен возвращать undefined, если вы хотите разрешить соединение, и генерировать исключение в противном случае (хотя я не знаю, будет ли request проксировать этот флаг через tls для вас) .) Может быть удобно объявить такую ​​функцию и console.log(host, cert); выяснить, что, черт возьми, происходит.

{
  method: 'POST',
  hostname: 'api.dropbox.com',
  port: 443
}

[ server_extension ]
       .
       .
       .

subjectAltName          = @alt_names_server

[alt_names_server]
IP.1 = x.x.x.x

export OPENSSL_CONF=intermed-ca.cnf

openssl ca \
    -in server.req.pem \
    -out server.cert.pem \
    -extensions server_extension \
    -startdate `date +%y%m%d000000Z -u -d -2day` \
    -enddate `date +%y%m%d000000Z -u -d +2years+1day`   

var transporter = nodemailer.createTransport({
            host: 'mail.site.com',
            port: 25,
            secure: false,
            auth: {
                user: 'info@site.com',
                pass: 'YOUR_PASSWORD'
            },
            tls: {
                rejectUnauthorized: false
            }
        });

Для разработчиков, использующих Fetch API в приложении Node.js. , вот как я получил это с помощью rejectUnauthorized.

Имейте в виду, что использование rejectUnauthorized опасно, поскольку оно открывает для вас потенциальные риски безопасности, поскольку позволяет обойти проблемный сертификат.

const fetch = require("node-fetch");
const https = require('https');

const httpsAgent = new https.Agent({
  rejectUnauthorized: false,
});

async function getData() {
  const resp = await fetch(
    "https://myexampleapi.com/endpoint",
    {
      agent: httpsAgent,
    },
  )
  const data = await resp.json()
  return data
}

1 Дек 2020 в 20:32

Чтобы устранить проблему для пакета http-proxy

1) HTTP (локальный хост) с доступом по HTTPS Чтобы устранить эту проблему, установите для changeOrigin значение true.

const proxy = httpProxy.createProxyServer();

proxy.web(req, res, {
  changeOrigin: true,
  target: https://example.com:3000,
});

2) HTTPS для доступа к HTTPS , вы должны включить сертификат SSL.

httpProxy.createServer({
  ssl: {
    key: fs.readFileSync('valid-ssl-key.pem', 'utf8'),
    cert: fs.readFileSync('valid-ssl-cert.pem', 'utf8')
  },
  target: 'https://example.com:3000',
  secure: true
}).listen(443);

1 Авг 2020 в 13:31

Если вы собираетесь доверять субдомену, например, aaa.localhost, Пожалуйста, не делайте этого как mkcert localhost *.localhost 127.0.0.1, это не сработает, поскольку некоторые браузеры не принимают поддомен с подстановочными знаками.

Может, попробуй mkcert localhost aaa.localhost 127.0.0.1.

После проверки того, что сертификат выпущен известным центром сертификации (CA), будут проверяться альтернативные имена субъектов или общее имя, чтобы убедиться, что имя хоста совпадает. Это находится в функции checkServerIdentity. Если сертификат имеет альтернативные имена субъектов и имя хоста не указано в списке, вы увидите следующее сообщение об ошибке:

Имя хоста / IP не совпадает с альтернативными именами сертификатов

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

var r = require('request');

var opts = {
    method: "POST",
    ca: fs.readFileSync("ca.cer")
};

r('https://api.dropbox.com', opts, function (error, response, body) {
    // do something
});

Это подтвердит, что сертификат выпущен предоставленным ЦС, но проверка имени хоста все равно будет выполняться. Достаточно просто предоставить CA, если сертификат содержит имя хоста в альтернативных именах субъектов. Если это не так, и вы также хотите пропустить проверку имени хоста, вы можете передать функцию noop для checkServerIdentity

var r = require('request');

var opts = {
    method: "POST",
    ca: fs.readFileSync("ca.cer"),
    agentOptions: { checkServerIdentity: function() {} }
};

r('https://api.dropbox.com', opts, function (error, response, body) {
    // do something
});

6 Июл 2018 в 04:10

import path from 'path';
import AWS from 'aws-sdk';

const { region, esEndpoint } = process.env;
const endpoint = new AWS.Endpoint(esEndpoint);
const httpClient = new AWS.HttpClient();
const credentials = new AWS.EnvironmentCredentials('AWS');

/**
 * Sends a request to Elasticsearch
 *
 * @param {string} httpMethod - The HTTP method, e.g. 'GET', 'PUT', 'DELETE', etc
 * @param {string} requestPath - The HTTP path (relative to the Elasticsearch domain), e.g. '.kibana'
 * @param {string} [payload] - An optional JavaScript object that will be serialized to the HTTP request body
 * @returns {Promise} Promise - object with the result of the HTTP response
 */
export function sendRequest ({ httpMethod, requestPath, payload }) {
    const request = new AWS.HttpRequest(endpoint, region);

    request.method = httpMethod;
    request.path = path.join(request.path, requestPath);
    request.body = payload;
    request.headers['Content-Type'] = 'application/json';
    request.headers['Host'] = '[es-domain-name].eu-west-1.es.amazonaws.com';
    request.headers['Content-Length'] = Buffer.byteLength(request.body);
    const signer = new AWS.Signers.V4(request, 'es');
    signer.addAuthorization(credentials, new Date());

    return new Promise((resolve, reject) => {
        httpClient.handleRequest(
            request,
            null,
            response => {
                const { statusCode, statusMessage, headers } = response;
                let body = '';
                response.on('data', chunk => {
                    body += chunk;
                });
                response.on('end', () => {
                    const data = {
                        statusCode,
                        statusMessage,
                        headers
                    };
                    if (body) {
                        data.body = JSON.parse(body);
                    }
                    resolve(data);
                });
            },
            err => {
                reject(err);
            }
        );
    });
}

17 Авг 2020 в 16:33

10 ответов

Чтобы это исправить, вам нужно предоставить дополнительный параметр openssl при создании сертификата, в основном

-sha256 -extfile v3.ext

Где v3.ext — такой же файл, с %%DOMAIN%% заменяется тем же именем, которое вы используете в качестве Common Name. Подробнее здесь и здесь. Обратите внимание, что обычно вы устанавливаете Common Name и %%DOMAIN%% для домена, для которого вы пытаетесь создать сертификат. Так что если бы это было www.mysupersite.com, то вы бы использовали это для обоих.

V3.ext

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = %%DOMAIN%%

Примечание. Сценарии, которые решают эту проблему, и создать полностью доверенные сертификаты ssl для использования в Chrome, Safari и от клиентов Java можно найти здесь

20 Июн 2020 в 09:12

sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -sha256 -subj '/CN=my-domain.com/subjectAltName=DNS.1=192.168.0.222/' -keyout my-domain.key -out my-domain.crt

Вы можете добавить другие атрибуты, такие как C, ST, L, O, OU, emailAddress, чтобы генерировать сертификаты без запроса.

26 Июл 2017 в 17:53

У меня было очень много проблем с получением самозаверяющих сертификатов, работающих на macos / Chrome. Наконец, я обнаружил Mkcert: «Простой инструмент с нулевой конфигурацией для создания локально доверенных сертификатов разработки с любыми именами, которые вы хотите». https://github.com/FiloSottile/mkcert

6 Дек 2019 в 00:48

• Сделайте копию вашей конфигурации OpenSSL в вашем домашнем каталоге:

  cp /System/Library/OpenSSL/openssl.cnf ~/openssl-temp.cnf
  

  или в Linux:

  cp /etc/ssl/openssl.cnf ~/openssl-temp.cnf
  

• [ v3_ca ]
  subjectAltName = DNS:localhost
  

  Замените localhost доменом, для которого вы хотите создать этот сертификат.

• sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
      -config ~/openssl-temp.cnf
      -keyout /path/to/your.key -out /path/to/your.crt
  

Затем вы можете удалить openssl-temp.cnf

10 Июн 2019 в 17:20

Вот очень простой способ создать IP-сертификат, которому Chrome будет доверять.

[ req ]
default_bits       = 4096
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt             = no

[ req_distinguished_name ]
commonName                  = 192.168.1.10

[ req_ext ]
subjectAltName = IP:192.168.1.10

openssl genrsa -out key1.pem
openssl req -new -key key1.pem -out csr1.pem -config ssl.conf
openssl x509 -req -days 9999 -in csr1.pem -signkey key1.pem -out cert1.pem -extensions req_ext -extfile ssl.conf
rm csr1.pem

В Windows импортируйте сертификат в хранилище доверенных корневых сертификатов на всех клиентских компьютерах. На Android Phone или Tablet загрузите сертификат для его установки. Теперь Chrome будет доверять сертификату на windows и Android.

На Windows Dev Box лучшее место, чтобы получить openssl.exe из «c: \ Program Files \ Git \ usr \ bin \ openssl.exe»

2 Окт 2019 в 22:41

Если вы хотите запустить локальный сервер на своем сервере, вам необходимо настроить CN = localhost и DNS.1 = localhost.

[req]
default_bits = 2048
default_md = sha256
distinguished_name = req_distinguished_name
prompt = no
prompt = no
x509_extensions = v3_req

[req_distinguished_name]
C = BR
CN = localhost
emailAddress=contact@example.com
L = Sao Paulo
O = example.com
OU = example.com
ST = Sao Paulo

[v3_req]
authorityKeyIdentifier = keyid, issuer
basicConstraints = CA:FALSE
extendedKeyUsage = serverAuth
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost

9 Авг 2020 в 04:06

Мне удалось избавиться от (net :: ERR_CERT_AUTHORITY_INVALID), изменив значение DNS.1 файла v3.ext

Измените domainname.com своим собственным доменом.

16 Май 2017 в 11:51

Следующее решение работает для меня в Chrome 65 (ref) —

Создайте файл конфигурации OpenSSL (пример: req.cnf)

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = VA
L = SomeCity
O = MyCompany
OU = MyDivision
CN = www.company.com
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.company.com
DNS.2 = company.com
DNS.3 = company.net

Создайте сертификат, ссылающийся на этот файл конфигурации

openssl req -x509 -nodes -days 730 -newkey rsa:2048 \
 -keyout cert.key -out cert.pem -config req.cnf -sha256

6 Апр 2018 в 12:00

Bash Script

Я создал сценарий bash , чтобы упростить создание самозаверяющих сертификатов TLS, действительных в Chrome.

Протестировано на Chrome 65.x и все еще работает. Обязательно перезапустите Chrome после установки новых сертификатов.

chrome://restart

Другие источники

24 Июл 2020 в 22:30

На MAC начиная с версии Chrome 67.0.3396.99 мой самозаверяющий сертификат перестал работать.

Регенерация со всем, что написано здесь, не сработало.

< Сильный > UPDATE

Был шанс подтвердить, что мой подход работает сегодня :). Если это не работает для вас, убедитесь, что вы используете этот подход

v3.ext
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names

[alt_names]
DNS.1 = <specify-the-same-common-name-that-you-used-while-generating-csr-in-the-last-step>
$

Скопировано отсюда https://ksearch.wordpress.com/2017/08/22/generate-and-import-a-self-signed-ssl-certificate-on-mac-osx-sierra/

Наконец-то смог увидеть зеленый Secure только когда удалил мой сертификат из системы и добавил его в локальную цепочку для ключей. (если есть — бросьте первым). Не уверен, имеет ли это значение, но в моем случае я скачал сертификат через chrome и проверил, что дата создания сегодня — поэтому я только что создал.

Надеюсь, что это будет полезно для кого-то потратить как день на это

никогда не обновлять Chrome!