вторник, 12 апреля 2011, Малеев Дмитрий

Цифровой сертификат — выпущенный удостоверяющим центром электронный или печатный документ, подтверждающий принадлежность владельцу открытого ключа или каких-либо атрибутов.

(с)Wikipedia

В прошлый раз мы говорили о том, что можно найдти в файле описании нашего сервиса. Там и даже ещё раньше я заикался о мистических сертификатах, которые мы можем использовать. Давайте вначале разберемся зачем нам это надо и куда мы с этим сертификатом можем идти?

В основном, в интернете используется так званый X.509 сертификат.

Что это такое?

Это просто цифровой документ, который содержит в себе публичный ключ, а так же информацию о том что публичный ключ принадлежит именно какому - то человеку - компании. Используется сие для достаточно многих вещей, организация HTTPS, авторизация, и т.д и т.п.

Для чего в Ажуре?

Ну во первых, для все того же HTTPS. Вы можете открыть HTTPS соединение только в случае существования сертификата. Во-вторых, вы можете использовать определенную бизнесс логику, которая будет что - то проверять с помощью сертификату. В-третьих, Вы сможете апдейтить свое сервиса на Ажуре прямо из Visual Studio, но только с помощью определенного сертификата. При чем сертификат должен быть одинаковый как на Вашей машине, так и на виртуальной машине где крутиться веб роль которую вы хотите апдейтнуть. Как видим, сертификаты достаточно важная и незаменимая штука при работе с Ажуром. Но обо всем по-порядку.

Где взять сертификат?

Вот тут вопрос сложный. Вы можете его сгенерить самостоятельно, про что я ещё Вам расскажу. Ну сами представте, к Вам на сайт приходит человек, который очень озабочень секретностью данных которыми обменивается он и Ваша аппликация. И тут ему высвечивается табличка, что нужно получить сертификат, который создан в подвале дома номер 40, квартира 15, Вася Пупкиным. Ессно пользователь скажет что такие сертификаты ему не нужны и навсегда забудет про Ваше приложение, каким бы классным оно небыло.

Вот, потому в один момент я начал колупать где же взять настоящие сертификаты, и скажу Вам был очень удивлен, когда узнал что вот эти пару килобайт информации могут стоить от 1к вечнозеленых купюр. Ага. Но это уже будут проверенные сертификаты, которые не склепанные Вами на коленке, а верифицированные крупными фирмами.

Есть ещё и вторая сторона медали - иногда Вы не можете использовать сертификаты которые купленны в других фирмах. Давайте, допустим ситцацию - Вы супер секретная организация, которая торгует супер вещью Х. Сделать заказ может только менеджер с компьютера в Вашей системе - для этого Вы всем менеджерам выдаете сертификат с публичным ключем, а сертификат с приватным - лежит на сервере. Вот эти два ключа вы используете для аусентикации пользователя. Тут уже ключ сгенерен именно Вами и именно для Вашей организации.

Опять же, когда вы тестируете свое приложение - не стоит сразу покупать сертификат, на тестовый период можно использовать собственноручно сгенеренный.

Как сгенерить?

Тут просто, главное не запутаться:) С .Net идет встроенная отличная тулза, которая зовется makecert. У нее очень много параметров которые можна задавать чтобы создать сертификат именно под Ваши нужды.

Пример исползьвания этого приложения может выглядеть так:

makecert -r -pe -n "CN=MySite.com Dev" -b 01/01/2000 -e 01/01/2033 -eku 1.3.6.1.5.5.7.3.1 -ss Root -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 mycert.cer

Вот эта комманда сгенерит нам сертификат под название mycert.cer.

Ну сертификат есть, че дальше?

Собстевнно на картинке все показанно, мы просто должны выбрать пункт меню на Ажур портале под название "Management Certificates" и там выбрать "Add Certificate". В открывшемся окне стоит дать путь на физическое распололжение сертификата.

Как добавить со студии?

Вообще я предпологаю что можно это и погиковски сделать - тоесть через XML. Но, как и раньше, я все буду делать аки блондинка:) Открываем свойства необходимой роли, и видим там закладку сертификатов.

Там, с помощью UI выбираем где найти наш сертификат расположен на нашей машине. После, давайте глянем что там с файлом описания нашего сервиса?

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureProject1" 
xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="TestApplication1">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
    <ConfigurationSettings>
      <Setting name="MyCustomSettingInAzure" />
    </ConfigurationSettings>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
  </WebRole>
  <WebRole name="SecondRole">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="8080" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
    <LocalResources>
      <LocalStorage name="LocalStorage1" cleanOnRoleRecycle="true" 
sizeInMB="100" />
    </LocalResources>
    <Certificates>
      <Certificate name="temporaryTestingCertificate" storeLocation="LocalMachine" 
storeName="TrustedPeople" />
    </Certificates>
  </WebRole>
  <WorkerRole name="WorkerRole1">
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="tcp" port="10000" />
    </Endpoints>
  </WorkerRole>
</ServiceDefinition>

Как вижим, для второй роли появилась секция сертификатов, в которой указанно где данный сертификат лежит на нашей машине.

Теперь мы можем выставить использование нашего сертификата для ендпоинта.

В течении двух постов Мы с Вами полностью обсудили что можна делать с описанием сервиса, как его менять и какие настройки добавлять. Помните, что в случае если вы захотите поменять этой файл - у вас изменились настройки, или вы хотите виртуальную машину пошустрее - чтобы апдейтнуть этой файл, машину вначале надо выключить. Потому, если Ваше приложение крутиться на Ажуре, и вы расчитваете изменить описание Вашего сервиса - это должен быть спланированный шаг, чтобы пользователи Вашего приложения понесли как можно меньше негативных эмоций, когда увидят что Ваше приложение в дауне.

---

Теперь, я бы хотел поговрить о втором файле, конфигурационном. Тот что с разширением *.cscfg.

Что у нас тут?

Радостная новость - этот файл можна заменять, даже не перегружая роль:) Единственное что - особо важных настроек кроме количесвта инстансов роли тут нет. Хотя, все настройки одинаково важны. Могут быть огрехи в архитектуре. Итак, что мы тут можем задать? - Количество инстаннсов для роли. - Отпечаток сертификата (я действительно не знаю как перевести Thumbprint :) ) - Значение собственных параметров. Про них мы активно говорили в предыдущих постах.

Чтобы не обсуждать чет мифическое, давайте глянем на формат этого файла сейчас:

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="WindowsAzureProject1" xmlns="
http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" 
osVersion="*">
  <Role name="TestApplication1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="
UseDevelopmentStorage=true" />
      <Setting name="MyCustomSettingInAzure" value="ыыы" />
    </ConfigurationSettings>
  </Role>
  <Role name="SecondRole">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="
UseDevelopmentStorage=true" />
    </ConfigurationSettings>
    <Certificates>
      <Certificate name="temporaryTestingCertificate" thumbprint="
E6AE81BB1E818D04BE3EBBE09E8A4B4EB42D5B73" thumbprintAlgorithm="sha1" />
    </Certificates>
  </Role>
  <Role name="WorkerRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="
UseDevelopmentStorage=true" />
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration>

Как видим, как и в предидущем случае для каждой роли есть своя секция. Да, и ещё тут куча инфы которая осталась от наших прежних эксперементов.

Давайте с каждым элементом по очереди разберемся:

<Instances count="1" />

Как видим, эта штука есть у всех ролей. Этот параметр указывает количество виртуальных машин, которые будут подняты с Вашей ролью. Тут надо быть аккуратней, ибо за то сколько машин вы тут укажите - за то количество и заплатите:) Так что, из-за невнимательности можна прилично попасть на денежку.

<Certificates>
      <Certificate name="temporaryTestingCertificate" 
thumbprint="E6AE81BB1E818D04BE3EBBE09E8A4B4EB42D5B73" thumbprintAlgorithm="sha1" />
</Certificates>

Тут соверешенно логичный вопрос - че? Почему настройки разибты аж на 2 файла. Давайте думать: 1. Мы с Вами говорили , что иногда будем пользовать тестовый сертфикат. Следовательно перед продакшеном мы купим сертификат и будем уже испольщовать другой. 2. У сертификатов есть срок действия, тоесть сертификат в самый неожиданный момент может завалится, и с этим завалить Вашу систему. Тоесть сертификат - штука не постоянная, а меняющаяся. Теперь прикиньте как будут недовольны Ваши пользователи, если для того чтобы поменять сертификат - вы завалите приложение которое они в данный момент активно используют.

Тут главное не теряться в слове Name. Это не физическое имя сертификата, ага. Это внутренняя настройка Ажура, по которой он знает о какой настроки в конфигурацинном файле идет речь. Сам сертификат получается через "отпечаток сертификата " ( вот так я это для себя назвал). Эта штука - это уникальный код по которому можна найди нужный нам сертфиикат Потому, если мы меняем сертификат, мы просто меняем его отпечаток, и в следующий раз когда наше приложение будет обращаться к сертификату - оно уже дернет новый сертификат. А так как эта настройка в файле конфигурации - даже роли перегружать не прийдется.

Про собственный настройки я уже писал, потому останавливаться на них не буду.

Как же их поменять, если надо?

Да прям с портала. Стоит всего лиш выбрать ваш деплой , и тыцнуть кнопку Conigure. В всплывшем окошке нужно изменить необходимые настройки.

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

RoleEnvironment.Changing RoleEnvironment.Changed

Очень хочется верить что по названиям ивентов понятно когда и почему они происходят:)

Ну че, вроде заменяет web.config? Ну не полностью:) Вообще, к приложениям которые будут крутиться на Ажуре, стоит приглядываться более детально, ибо законы которые работают на обычных приложениях, слегка измененны в приложениях для Ажура.

Что мы обычно храним в web.config?

Conneciton string к базе данных. Вот эта штука может меняться. Если вы создаете сайт, в котором коннекшен стринг будет хранится в web.config - фиг вы его поменяете, без редеплоя приложения , что приведет к тому что оно у вас будет недоступно приличное время. Потому, если вы планируете менять эту строчку ( допустим переход из стейджинг версии в продакшен ), стоит подумать об том чтобы ее перенести в файл конфигурации.

Конфигурацию билда Оно вам надо его менять когда оно в ажуре. Лежало себе в web.config - хай и дальше лежит:)

Разного рода настройки Тут зависит от настройки - если оно никак не влияет на то как работают части - пихайте в конфигурационный файл. Если же это, допустим, настройки таймаутов - то редеплоя все равно не избежать. Оно вам надо мучаться - пихайте в web.config, все равно перегружать тачку.

Endpoints Логично, что меняться тут может только аддресс сервиса который мы будем пользовать. Потому - самый здравый выбор, все настройки которые меняться не будут - оставить в web.config, а вот урлу сохранить в конфигурационном файле, и сделать так, чтобы исходный код знал, что урлу сервиса стоит брать именно оттуда.

---