Раніше деякі сертифікати SSL підтримували захист локальних доменів. Зараз ні випустити, ні перевипустити чи продовжити такий сертифікат не можна. Поле SAN (Subject Alternative Name) або Subject Common Name має містити тільки FQDN (Fully Qualified Domain Name).
Які частини мережі торкнулися?
Сертифікат не можна випустити на внутрішні домени та зарезервовані адреси приватної мережі.
- Хостнейми виду:
- server1
- printspool
- TLD для внутрішнього використання:
- .test
- .example
- .invalid
- .localhost
- .local
- .lan
- .priv
- .localdomain
- Сірі IP-адреси (серії RFC 1918):
- 10.0.0.0 – 10.255.255.255
- 172.16.0.0 – 172.31.255.255
- 192.168.0.0 – 192.168.255.255
- IPv6 серії RFC 4193 (внутрішні та не доступні з Інтернету).
Хто і чому скасував таку нагоду?
Це рішення прийняв Форум Центрів сертифікації та браузерів (CA/B Forum) — консорціум Центрів сертифікації, вендорів браузерів та інших постачальників ПЗ, що використовує стандарт криптографії X.509 v.3 для SSL/TLS та підпису коду. Це свого роду законодавчий орган у питаннях SSL/TLS.
Оскільки внутрішні мережні адреси та імена не є унікальними, їх не можна ідентифікувати поза цією мережею. Таких імен може бути тисячі. Це дає можливість хакерам успішно зробити атаку «людина посередині» (man in the middle) і отримати конфіденційну інформацію, що зводить нанівець зусилля захистити дані за допомогою сертифіката. Тоді як зареєстрований домен може використовувати лише один власник, хай і для кількох серверів.
Таким чином форум намагається зробити інтернет безпечнішим, а дані користувача — захищеними.
Які слід зробити дії?
Серед представлених на нашому сайті сертифікатів лише Comodo Unified Communications підтримував внутрішні домени. Якщо ви випускали його та додавали до SAN внутрішні імена, він буде дійсним до 1 жовтня 2016 року або до закінчення терміну дії сертифіката, якщо ця дата настане раніше. Тому надалі можна буде використовувати самопідписані сертифікати, або змінювати конфігурацію сервера та його внутрішніх служб для роботи з цілком певними доменними іменами.