Могу ли я сгенерировать CSR для удаленного сервера и какой сервер мне следует использовать (thin,mongrel)?
Я перевожу свое приложение в производство и мне нужна помощь в создании КСО. Я создал закрытый ключ и выполнил следующие действия:
- Создан закрытый ключ
- Введенный пароль для него (
openssl genrsa -des3 -out domainname.key 1024) - Создано CSR (
openssl req -new -key domainname.key -out domainname.csr) - В CSR я ввел всю информацию. Общее название было в формате:
XX.XXX.XXX:3000где Х это число.
Наконец, я сгенерировал CSR, но на этом этапе мое приложение находится на удаленном сервере с IP-адресом http://XX.XXX.XXX.XXX:3000/ и на thawte.com при генерации пробного SSL он показывает мне ошибку:
The Common Name in the CSR is invalid.
Кто-нибудь имел подобную задачу и может посоветовать мне, что я сделал не так?
Второй вопрос: какой сервер вы мне порекомендуете и, соответственно, какую веб-платформу (при генерации SSL) я должен выбрать в списке?
3 ответа
Общие имена не содержат номеров портов или двоеточий, таких как :3000, Они не должны быть IP-адресом. Они также не содержат идентификаторов протоколов, таких как https://,
Если память мне не изменяет, сами по себе числа недопустимы в качестве доменного имени (хотя они могут быть и для поддоменов), и нет домена верхнего уровня, который был бы просто числом. Ваше общее имя XX.XXX.XXX:3000 где X являются номерами не IP-адрес или имя домена.
Общее имя должно быть ничем иным, как полностью определенным доменным именем, для которого должен использоваться сертификат.
Ты можешь использовать *.example.com для общего имени, если вы запрашиваете подстановочный сертификат.
Если ваше приложение работает на порту 3000, вы должны запросить сертификат в обычном режиме, без номера порта, а затем указать клиентам использовать порт 3000. Если клиент является веб-браузером, это делается по URL-адресу: ` https://www.example.com:3000/"
Выбор "Веб-платформа" не является обязательным и позволяет Thawte предоставлять вам файлы в формате, необходимом для этого программного обеспечения. Например, nginx требует, чтобы сертификат и все цепные сертификаты были в одном файле в правильном порядке. Apache может хранить их в отдельных файлах и импортировать их как SSLCertificateFile а также SSLCertificateChainFile, Если ваш сайт работает на хорошо известном HTTP-сервере, который есть в списке, выберите это программное обеспечение. Если вы написали это самостоятельно или написали специальное программное обеспечение для вас, и его нет в списке, проконсультируйтесь с производителями программного обеспечения.
Общее имя было в формате: XX.XXX.XXX:3000, где X - номер
Во-первых, имя хоста или IP-адрес в сертификате не должны содержать порт.
Во-вторых, предполагая, что XX.XXX.XXX является IP-адресом, IP-адреса должны быть в записи Subject Alternative Name типа IP-адреса (не типа DNS и не в CN DN субъекта). См. RFC 2818:
В некоторых случаях URI указывается как IP-адрес, а не как
Имя хоста. В этом случае должен присутствовать iPAddress subjectAltName
в сертификате и должен точно соответствовать IP в URI.
Некоторые клиенты более спокойно относятся к этому, но это не причина для получения несоответствующего сертификата.
Я не уверен, что Thawte выдаст вам сертификат для IP-адреса, так как им довольно сложно проверить, кому принадлежит этот IP-адрес.
(Я немного удивлен, что они даже не хотят смотреть на CN, поскольку все, что им действительно нужно, это получить открытый ключ от CA и выдать сертификат только с тем, что они независимо проверяли, в любом случае.)
В поле Common Name должно быть указано полное доменное имя (FQDN) или веб-адрес, для которого вы планируете использовать свой сертификат, например, область вашего сайта, к которой вы хотите подключить клиентов с использованием SSL. Если веб-адресом, который будет использоваться для SSL, является www.example-name.com, убедитесь, что общее имя, представленное в CSR, - www.example-name.com; аналогично, если веб-адрес, который будет использоваться для SSL, - secure.example-name.com, убедитесь, что общее имя, представленное в CSR, - secure.example-name.com.