misc.google.com Сертификат выдается за неправильный домен [дубликат]
Вы также можете исправить эту проблему, используя аннотацию @Service в классе службы и передав требуемый bean classA в качестве параметра в другой конструктор класса bean bean и аннотировать конструктор класса B с @Autowired. Пример фрагмента здесь:
@Service
public class ClassB {
private ClassA classA;
@Autowired
public ClassB(ClassA classA) {
this.classA = classA;
}
public void useClassAObjectHere(){
classA.callMethodOnObjectA();
}
}
2 ответа
Чтобы быть абсолютно правильным, вы должны поместить все имена в поле SAN.
Поле CN должно содержать имя субъекта, а не имя домена, но когда Netscape обнаружил эту вещь SSL, они пропустили чтобы определить его самый большой рынок. Просто не было поля сертификата, определенного для URL-адреса сервера.
Было решено помещать домен в поле CN, и в настоящее время использование поля CN устарело, но все еще широко используется. CN может содержать только одно доменное имя.
Общие правила для этого: CN - укажите здесь ваш основной URL (для совместимости) SAN - разместите здесь весь свой домен, повторите CN, потому что его не в нужном месте там, но его использовали для этого ...
Если вы нашли правильную реализацию, ответы на ваши вопросы будут следующими:
- У этой настройки особое значение , или какие-либо преимущества, связанные с установкой обоих CN? Вы не можете установить оба CN, потому что CN может содержать только одно имя. Вы можете сделать с помощью двух простых CN-сертификатов вместо одного CN + SAN-сертификата, но для этого вам нужно 2 IP-адреса.
- Что происходит на стороне сервера, если другой, host.domain.tld, просил? Не имеет значения, что происходит на стороне сервера.
Вкратце: когда клиент-браузер подключается к этому серверу, браузер отправляет зашифрованные пакеты, которые зашифровываются открытым ключом сервер. Сервер расшифровывает пакет, и если сервер может расшифровать, то он был зашифрован для сервера.
Сервер не знает ничего от клиента перед расшифровкой, поскольку только IP-адрес не зашифрован через соединение. Вот почему вам нужно 2 IP-адреса для 2-х сертификатов. (Забудьте о SNI, там слишком много XP).
На стороне клиента браузер получает CN, затем SAN, пока все из них не будут проверены. Если одно из имен соответствует сайту, проверка URL-адресов была выполнена браузером. (im, не говоря о проверке сертификата, конечно, много ocsp, crl, aia запрос и ответы каждый раз ходят в сети.)
-
1Является ли это короткое замыкание вообще? Я имею в виду, что SAN всегда проверяются первым, и если они найдены, CN не проверяется вообще? – Jürgen Thelen 9 May 2011 в 14:36
-
2
-
3Если вы имеете дело с IE, он, как представляется, игнорирует CN, если присутствует имя subjectAltName. Я видел, как IE10 и IE8 жалуются на несоответствие имени в подобных случаях. – Eric 22 October 2013 в 22:06
-
4Это неверно в отношении сертификатов SSL. Подробнее см. В этом ответе. TL; DR RFC 5280 является общим для структур PKI. RFC2818 и RFC5216 (для HTTPS) заявляют, что если SAN присутствует, он ДОЛЖЕН использоваться для идентификации. – JonoCoetzee 22 September 2014 в 13:39
-
5@Eugene Mayevski 'EldoS Corp Да, извините RFC5216 не для HTTPS, они запутались. Несмотря на то, что Chrome теперь выдает ошибку ERR_CERT_COMMON_NAME_INVALID, поскольку он использует исключительно SAN (если присутствует). – JonoCoetzee 22 September 2014 в 15:53
-
6Это правило базового требования CABForum не очень полезно технически. Он просто говорит вам, что положить в CN, но это, конечно, не означает, что CN используется для проверки в любом случае. Имеет смысл иметь CN как одну из сетей SAN, но это в основном полезно для инструментов и административных целей (или против слишком быстрой реализации). С точки зрения верификации RFC 2818 (« Если расширение типа subjectAltName типа dNSName присутствует, которое ДОЛЖНО использоваться как идентификатор ») и даже RFC 6125, во многом предшествует этой спецификации, и это конкретное правило все еще действует в обоих случаях. – Bruno 13 April 2015 в 10:06
-
7