Доколкото разбирам, всъщност е възможно да се създаде сертификат, издаден на IP адрес. Възможно ли е да се направи това в IIS Express?
Моля, имайте предвид, че това е само за тестване.
Редактиране
Хората изглежда пропускат истинското месо и картофи на моя въпрос, така че премахнах допълнителните подробности.
Благодаря ти @Bruno за всички твои предложения!! Използването на отделен инструмент за създаване на SSL сертификат ме насочи в правилната посока.
Първо изпробвах инструмента за команден ред на IIS 6 selfssl, който вероятно щеше да свърши работа и за първа стъпка, за да накарам това да работи (но не съм го тествал, след като намерих настоящото си решение). Първата стъпка е създаването на сертификата, а втората стъпка е да обвържа този сертификат с моя IP/порт.
Използвах makecert от Visual Studio Команден ред за създаване на моя сертификат (тук мисля, че инструментът IIS 6 selfssl от IIS 6 Resource Kit също трябва да работи). След като създадох сертификата, го намерих под Лични/Сертификати, като използвах конзолата за конзола mmc и добавих конзолата за сертификати.
makecert -r -pe -n "CN=0.0.0.0" -b 01/01/2011 -e 01/01/2025 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12
За да обвържа сертификата с моя IP/порт, използвах netsh. ipport трябва да се промени на вашия IP/порт. appid е GUID и не вярвам, че това има значение на какво сте го задали. certhash можете да получите от полето Thumbnail на самия сертификат, но трябва да премахнете интервалите в хеша.
netsh http add sslcert ipport=0.0.0.0:44300 appid={AnyGuid} certhash=YourCertificateThumbprint
Както казах в този отговор:
За да бъде SSL/TLS защитен, трябва да имате поне 3 точки:
Втората и третата точка се прилагат от вашия сертификат. Изправени сте пред проблем по отношение на третата точка: проверка на името на хоста.
Използването на самоподписан сертификат е заместител на използването на сертификат, издаден от CA (част от PKI). Това ви казва дали можете да се доверите на съдържанието на сертификата, че е истинско (както се твърди от издателя). Чрез издаването и използването на самоподписан сертификат вие сами заявявате неговото съдържание. Вашите клиенти ще трябва да се доверят изрично на това, което казвате. Това е добре за малки внедрявания, където можете да убедите клиентите да инсталират вашия самоподписан сертификат като доверен сертификат.
Проверката на името на хоста е задължителна стъпка след това. Ако проверявате самоличността на някого, като използвате неговия паспорт, не е достатъчно да проверявате дали това е истински паспорт от страна, която познавате: трябва също така да проверите дали снимката съвпада с лицето пред вас. Същото важи и тук: това, към което искате да се свържете, получава името на хоста (или IP адреса) и то трябва да съвпада с името на хоста (или IP адреса) в сертификата, който ви е представен.
Разбира се, localhost е достъпен само от самата локална машина, малко като да кажете "аз". Като сървър се нуждаете от името в сертификата, за да бъде това, което вашите клиенти ще ви наричат. Обикновено е по-добре да направите това, като използвате име на хост, а не IP адрес. Имайте предвид, че според RFC 2818, ако използвате IP адрес, също трябва да бъде в разширението за алтернативно име на тема (въпреки че някои браузъри ще бъдат гъвкави по отношение на това изискване).
(Може също да се интересувате от този отговор. Въпреки че става въпрос за Java сървър, принципите са същите, тъй като сертификатът проверката зависи от клиента, която може да бъде на всеки език.)
РЕДАКТИРАНЕ: (Премахнахте голяма част от първоначалния си въпрос, така че отговорът ми по-горе може да няма напълно смисъл...)
Накратко, да, можете да генерирате сертификат, който идентифицира машина чрез IP адрес.
На теория (RFC 2818), IP адресът трябва да е в алтернативните имена на субекти (SAN) разширение на вашия сертификат (ще бъде SAN от тип "IP", а не "DNS"). Въпреки това, на практика този конкретен раздел от спецификацията се следва само свободно, така че вероятно бихте искали вашият IP адрес да бъде включен в общото име (CN) на вашия субект DN. Ако браузърите не успеят да внедрят RFC 2818 в достатъчна степен, може дори да успеете да използвате само CN=your.ip.address в DN на темата, без да се налага запис в SAN. (Клиентите на Java изглежда са стриктни по отношение на това, но това може да не е необходимо за вашия тестов случай.)
Не съм сигурен с какво генерирате сертификата си. За съжаление makecert.exe изглежда не може да генерира сертификати със SAN.
В този случай можете да генерирате самоподписан сертификат с помощта на OpenSSL например (вижте бележките в долната част на този отговор). Ако е необходимо, създайте PKCS#12 (с разширение .pfx или .p12 файл от вашия личен ключ и генериран сертификат (openssl pkcs12 -export -in cert.pem -inkey privkey.pem -out store.pfx). След това разгледайте конфигурирането на сертификата във вашия .pfx файл в IIS Express. Ще трябва да импортирате сертификата и частен ключ във вашето хранилище за сертификати (най-вероятно двукратното щракване трябва да задейства десния диалог). След това го използвайте (сякаш идва от CA); в зависимост от това как конфигурирате IIS, може да се наложи да включва netsh , Изглежда има урок тук: http://blogs.blackmarble.co.uk/blogs/rfennell/post/2011/03/22/how-to-expose-iis-express-to-external-network-connections-and-use-a-non-self-signed-certificate.aspx (Командите netsh също са изброени в този въпрос, споменат от @MrZombie: ще трябва да намерите хеша на вашия самоподписан сертификат, като разгледате инсталираните си сертификати и адаптирате номера на порта според вашата настройка.)
Доколкото разбирам проблема, освен ако сертификатът ви не е издаден от сертифициращ орган с действителна надеждност, ще продължите да получавате грешката.
(Под „надежден сертифициращ орган“ имам предвид „места, от които купувате сертификати“)
http://www.gerv.net/security/self-signed-certs/ ‹-- Интересно четиво по този въпрос.
