Можно ли использовать subjectAltName с однословными доменами? [дубликат]

Личный опыт

Некоторое время назад у меня была похожая проблема.

Я установил локальный DNS для серверов Windows и Linux с .staging в качестве ДВУ. Экономия на создании и подписании сертификатов для каждого виртуального узла и избегая необходимости настраивать новые IP-адреса (не-SNI веб-серверы), я создал key и cert для *.staging, но все клиенты, которых я пробовал (включая скручивание) только сообщил, что имя субъекта сертификата *.staging не совпадает с целевым узлом. Имя всякий раз, когда я пытался загрузить виртуальные узлы на наш сервер Staging с помощью TLS.

Relevant RFCs

Я потратил много времени, пытаясь выяснить, почему wildcard сертификат, который я создал потому что *.постановка не сработает. Я прочитал все соответствующие КСФ, но ни одна из них специально указано, что такой сертификат подстановочного знака является недействительным или незаконным.

• Использование TLS с IMAP, POP3 и ACAP
• HTTP по TLS
• Представление и проверка идентичности службы доменных приложений в инфраструктуре открытого ключа Интернета с использованием X.509. (PKIX) Сертификаты в контексте безопасности транспортного уровня (TLS)

Security Stack Exchange Answers

Я был в конце концов просвещен после прочтения этого отличного ответа Security Stack Exchange.

Важно то, что SSL клиенты примут как "действительный сертификат", т.е. сертификат, включающий имя, "совпадающее" с предполагаемым именем сервера. (тот, который включен в URL). Это номинально указано в RFC 2818, раздел 3.1, и он допускает многие виды подстановочных имен, в том числе такие вещи, как "www.*.*c*", совпадающие (теоретически) с любым именем сервера. содержащий три компонента, первый из которых "www", а второй - "www". содержащих по крайней мере один "c".

...

Итак, поставщики браузеров сделали свои собственные схемы и ограничения. Намного позже был опубликован новый документ RFC (6125, с марта 2011 года), раздел 6.4.3 которого содержит . посвященный обработке подстановочных имен в сертификатах. Что RFC 6125 Описание больше соответствует реальности, а является "предлагаемым стандартом", так что есть хоть какая-то воля, на каком-то уровне, чтобы это произошло. Однако, ничто в RFC 6125 не обязывает отклонять *.com; однако браузеры делают отклоняющими оно.

принял ответ на Может быть выдан SSL-сертификат со спецсимволом для второго уровня. Домен? также заслуживал повышения.

Edit

I figured that but but recountinging personal frustration, my answer на самом деле не добавляет многого, кроме как ссылки на RFC и соответствующие ответы на вопросы по обмену стеками безопасности; я подумал, что должен приложить больше усилий и ищите текущий соответствующий исходный код, используемый Chromium и Firefox.

Обратите внимание, что в комментариях к исходному коду Chromium явно указано, что неизвестные домены верхнего уровня (такие как *.интранет) запрещены.

Также: отсутствует ссылка на настраиваемую пользователем опцию, которая может переопределить Это поведение.

Исходный код Mozilla

Из центрального Mercurial Repository

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

if (isWildcard) {
  // If the DNS ID ends with a dot, the last dot signifies an absolute ID.
  size_t labelCount = (labelLength == 0) ? dotCount : (dotCount + 1);

  // Like NSS, require at least two labels to follow the wildcard label.
  //
  // TODO(bug XXXXXXX): Allow the TrustDomain to control this on a
  // per-eTLD+1 basis, similar to Chromium. Even then, it might be better to
  // still enforce that there are at least two labels after the wildcard.
  if (labelCount < 3) {
    return false;
  }
  // XXX: RFC6125 says that we shouldn't accept wildcards within an IDN
  // A-Label. The consequence of this is that we effectively discriminate
  // against users of languages that cannot be encoded with ASCII.
  if (StartsWithIDNALabel(hostname)) {
    return false;
  }

  // TODO(bug XXXXXXX): Wildcards are not allowed for EV certificates.
  // Provide an option to indicate whether wildcards should be matched, for
  // the purpose of helping the application enforce this.
}

Исходный код хрома

Из Chromium Git Repository

Не разрешают использовать подстановочные знаки для доменов, контролируемых открытым/ICANN реестром, - которые это, предотвратить *.com или *.co.uk как действительные представленные имена

Кроме того, неизвестные домены верхнего уровня (такие как "интранет" или новые домены)

. ДВУ/gTLDs, которые еще не добавлены в набор данных домена, контролируемого реестром) также являются имплицитно предотвращено.

if (!reference_domain.empty()) {
  DCHECK(reference_domain.starts_with("."));

  // Do not allow wildcards for public/ICANN registry controlled domains -
  // that is, prevent *.com or *.co.uk as valid presented names, but do not
  // prevent *.appspot.com (a private registry controlled domain).
  // In addition, unknown top-level domains (such as 'intranet' domains or
  // new TLDs/gTLDs not yet added to the registry controlled domain dataset)
  // are also implicitly prevented.
  // Because |reference_domain| must contain at least one name component that
  // is not registry controlled, this ensures that all reference domains
  // contain at least three domain components when using wildcards.
  size_t registry_length =
      registry_controlled_domains::GetRegistryLength(
          reference_name,
          registry_controlled_domains::INCLUDE_UNKNOWN_REGISTRIES,
          registry_controlled_domains::EXCLUDE_PRIVATE_REGISTRIES);

  // Because |reference_name| was already canonicalized, the following
  // should never happen.
  CHECK_NE(std::string::npos, registry_length);

  // Account for the leading dot in |reference_domain|.
  bool is_registry_controlled =
      registry_length != 0 &&
      registry_length == (reference_domain.size() - 1);

  // Additionally, do not attempt wildcard matching for purely numeric
  // hostnames.
  allow_wildcards =
      !is_registry_controlled &&
      reference_name.find_first_not_of("0123456789.") != std::string::npos;
}

Комментарии в registry_controlled_domain.h также уместны:

RegistryControlledDomainService исследует имя хоста переданного GURL и определяет самую длинную часть, которая контролируется регистратором. Хотя технически домен верхнего уровня (ДВУ) для имени хоста является последним. точечное разделение имени (например, .com или .org), многие домены (например, co.uk) функционируют так, как если бы они были ДВУ, выделяя любое количество более специфических, по сути, не связанные с ними имена под ними. Например, .uk - это ДВУ, но никому не разрешается регистрировать домен непосредственно под доменом .uk; "действует". ДВУ - это ак.юк, ко.юк и так далее. Мы бы не хотели, чтобы какой-нибудь сайт в *.co.uk установить cookie для всего домена co.uk, так что важно быть способных определить, какие домены верхнего уровня функционируют как эффективные ДВУ, и которые могут быть зарегистрированы.

И Хром, и Mozilla основывают свое определение на эффективном TLD в открытом списке суффиксов в том виде, в каком он был опубликован. Mozilla.