Я думаю, тут ничего добавлять не надо, и так всё ясно. Но, всё-таки, скажу пару слов. Я этот бложек начал вести в 2008 и благополучно закончил в 2012. Нет, не потому что устал или вспотел, вовсе нет. Просто изменились приоритеты. Дело в том, что моя тематика (которую я тут раскрывал) не так востребована в данном регионе. Поскольку я окончательно переехал на буржуйские технеты, стало очень неудобно доставлять туда ссылки на русскоязычный бложек. Очевидные проблемы с логистикой и переводчиками.

Было бы обидно взять и пропустить всё написанное в шредер, поэтому я временно законсервирую бложек, отключу рсс и комментарии. Почему временно? Дело в том, что сейчас у меня творится полная каша с ресурсами. Имею два бложека, один на DasBlog, другой на шарике. Плюс, два проекта на кодеплексах, библиотеку API на SandCastle и всё это находится чёрти где. Поэтому у меня есть грандиозная идея создать свой уютненький портал (думается, на ASP MVC) в котором я объединю и как-то систематизирую все свои сайтики и бложеки. Но это пока в планах. Я тут пока занимаюсь текущими делами, плюс попутно изучаю WPF, MVC и что-то ещё (не могу вспомнить что именно). А пока оставлю всё как есть.

И всем спасибо за посильное участие в этом бложеке!

Monday, September 30, 2013 11:03:54 AM (FLE Daylight Time, UTC+03:00)   Comments [1]    

 

Напоминаю ещё раз, по ряду причин всё самое интересное сейчас я публикую только на буржуйском бложеке: http://en-us.sysadmins.lv/default.aspx. Сейчас там, например, идёт замечательная серия про использование Certificate Enrollment API в PowerShell. А потом (если получится), доставлю немного интересного про OCSP.

Sunday, July 08, 2012 10:17:37 PM (FLE Daylight Time, UTC+03:00)   Comments [2]    

 

Тут от одного пользователя поступила небольшая кучка вопросов. Вопросов достаточно и я решил их опубликовать и ответить в бложеке (оригинальная орфография сохранена). Вопросы в италике, ответы не в италике.

1. У вас практически во всех примерах не более трёх путей публикации (в некоторых обсуждениях - четыре) - два файловых локальных пути и
внешний web в самой статье. Когда вы пишите про LDAP, то пути также три - один файловый, внешний web  и LDAP. Это опять же связано с
таймаутом 20 секунд на обработку расширений? Т.е. больше - плохо?

Точек распространения файлов может быть сколько угодно. А вот точек публикаций не должно превышать 2-х, т.к. чисто технически 3-я (и последующие) работать уже не будут ни при каком раскладе. Об этом ниже.

2. Не могли ьы подсказать как поточнее считать таймауты? Первое правило - 10 сек, второе - 5 сек, 3 - 2.5-3 сек или  именно LDAP - 10 сек,
http - 5 сек?

Правило подсчёта простое: таймаут на первую ссылку (вне зависимости от протокола) в составляет 15 секунд. Вторая ссылка составляет 5 секунд. Однако, здесь действует ещё одно ограничение — общее время таймаута для обработки одного сертификата — 20 секунд. Если вы сложите эти таймауты, скорее всего (но не факт) получите число 20, что вываливается в факт, что если в сертификате указано 3 и более ссылок, CryptoAPI максимум осилит только 2, всё остальное отвалится по общему таймауту.

3. Есть ли таймаут на выкладывание (публикацию) сертификатов по указанным в конфигурации путям? Или сервер CA будет пытаться это сделать до
потери пульса?

таймауты есть, но про конкретные значения я не знаю. Вполне возможно, что это будут таймауты самих протоколов (SMB/LDAP).

4. Что-то поменялось в вашем отношении к публикации сертификатов и списков CRL в LDAP? Или вы по прежнему считаете, что это совершенно не
нужно? (я читал один из ваших постов, где вы пишите, что как раз занимались проектом, где чуть ли не только LDAP был). Если издаём на одном
сервере сертификаты и для внутренних и для внешних клиентов (а то и так три сервера - offline, IPCA, OSCP, при этом два - Enterprise), то
LDAP первым, а HTTP вторым или наоборот? А может быть всё-таки, как предложил Oleg - временно убирать из путей LDAP при выдаче сертификата
для внешнего ресурса (если таких немного и не часто это надо)? Тем более никто не мешает сделать wildcard-сертификат типа "*.contoso.com".

Я не думаю, что у меня это отношение поменялось, потому что я всегда был против публикации CRL'ов в LDAP кроме случаев исключительно внутреннего использования сертификатов. В этом случае использование LDAP вполне оправдано и целесообразно. В остальных случаях ссылки на LDAP в сертификатах фигурировать не должны.

5. Если у нас в AIA web-путь на OCSP задан третьей по счёту строчкой ("32:http://www.{adatum.com}/ocsp"), как будет отрабатывать клиент,
если это Виста и выше - сразу пойдёт проверять по OCSP или опять же по очереди?

Если клиент Vista+, его поведение при проверке отзыва сертификата будет следующим: сначала клиент заглянет в расширение AIA и поищет там ссылки на OCSP (если вы посмотрите на это расширение, вы увидите, что ссылки на OCSP и файлы CRT разделены разными методами доступа). При поиске ссылок OCSP ссылки на сертификат самого CA будут отброшены. Если статус отзыва при помощи OCSP не установлен, клиент переключается на расширение CDP и по очереди перебирает ссылки, пока статус сертификата не будет установлен.

6. Если у меня будут внесены CRT и CRL в LDAP (для RootCA и SubCA) и произойдёт, например обрыв связи между двумя AD-сайтами. В этом случае
смогут ли клиенты в отличном от SubCA-сервера сайте, у которых закрыт web (т.е. они не могут проверить сертификат по http),  проверять
валидность выданных сертификатов просто через свой контроллер Active Directory?

если случился обрыв связи, значит (скорее всего), репликация Active Directory происходить не будет. Следовательно, пока на локальном (в сайте) контроллере CRL'ы свежие — клиенты в сайте смогут проверять сертификаты. Как только CRL'ы протухнут, проверка сертификатов на отзыв будет фейлиться до восстановления репликации Active Directory.

http://www.sysadmins.lv/CommentView,guid,7cddb78e-fece-4d8a-8c85-813055311492.aspx
1. Зачем нам настраивать в принципе OCSP для Offline RootCA (что-то не нагуглил)? Чтобы можно было по этому механизму проверить всю цепочку
до сертификата RootCA, а не только отдельные CRL'и? Для этого разве недостаточно, что у нас будет поднят OCSP на издающем SubCA?

На самом деле бесполезно настраивать OCSP для корневых CA. И вот почему: среднестатистический запрос OCSP занимает 90 байт, ответ на него ~1,5kb. Учитывая специфику этих всяких offline CA (корневой и выделенный policy), их CRL будет почти всегда пуст. Или несколько отозванных сертификатов подчинённых CA. Среднестатистический CRL такого CA будет весить примерно 500 байт. Даже по трафику понятно, что для малодеятельных CA нет смысла настраивать OCSP. В упомянутой серии статей я просто хотел продемонстрировать, что вы можете настроить конфигурацию OCSP и для таких типов CA. Ни больше, ни меньше.

2. Для настройки OSCP для Offline Root CA система на нём должна быть Enterprise-редакции или достаточно Standard?

Если говорить о CA, достаточно и Standard. Для OCSP это совершенно безразлично на чём работает CA, хоть на линупсе. А вот Windows OCSP может быть установлен только на Enterprise и Datacenter редакции.

3. Тут есть вопрос и ваш ответ - посты от 25 апреля 2011 года про добавление шары "65:\\{servername}\...". Хочу уточнить - это, навреное,
касается всё-таки SubCA, а не RootCA (который Offline, не в сети и в сейфе :))?

разумеется. Поскольку offline CA не имеет никаких сетевых подключений, пути UNC лишены смысла (и вы это видите в указанном скрипте).

http://www.sysadmins.lv/CommentView,guid,bb8a9447-9b14-4540-add9-6df308129edd.aspx 
1. Можно ли безболезненно размещать на одном сервере SubCA (сервер Win 2008 R2 SP1 - просто член домена, не контроллер, сервис IIS) роли
Enterprise CA, OCSP, NDES? Или есть какие-то ньансы?

Технически вы можете всё. Например, установить CA/OCSP/NDES/CEP/CES/WebEnrollment на одной машине. Более того, вы туда можете доставить ещё контроллер домена, сервер Exchange, SharePoint Portal, Project Server, TMG, весь System Center и сделать хостом гипервизора. И особых нюансов здесь нету, кроме того, что это будет Адъ и Израель. На сервер CA я бы кроме роли самого CA других ролей и приложений не устанавливал.

Wednesday, May 30, 2012 8:28:50 PM (FLE Daylight Time, UTC+03:00)   Comments [16]    

 

И снова EFS. Казалось бы, над ним уже давно расставлены все точки, ан-нет, кому-то обязательно не будет покоя. А покоя сегодня нет по следующим поводам: EFS sharing и как правильно состряпать сертификат агента восстановленя EFS.

EFS sharing

Поступил по почте мне вопрос с ссылкой на ОСЗоне: http://forum.oszone.net/showthread.php?p=1922709. Краткое содержание серий:

Хочу сдать экзамен 70-642 (проектирование сетевой инфраструктуры Win2k8), читаю, тестирую, наткнулся на непонимание работы EFS по сети. Что написано в учебнике по 70-642:
"для совместного использования файлов с защитой EFS на локальном компьютере нужно добавить к файлу пользовательские сертификаты шифрования. Для совместного использования файлов по сети делать это не нужно, поскольку EFS предназначена для защиты доступа к файлам на локальном компьютере, и система Windows автоматически выполняет расшифровку файлов перед назначением общего доступа"

Честно говоря, я этот учебник не читал даже в оригинале и не могу сказать, правда ли так написано или нет. Возвращаемся к моему недавнему посту по теме. Из него следует, что шаринг файлов и шифрование сетевых файлов может сосуществовать (хотя, некоторые интернеты и отрицают это), т.е. не являются взаимоисключающими параграфами. Стало быть, вторая часть фразы из учебника не совсем верная. Вот как происходит процесс локально:

Цопирайт: картинка невозбранно стырена из религиозно-православной книжки Комара.

  1. Пользователь создаёт файл и хочет его зашифровать.
  2. В этот момент система генерирует симметричный ключ FEK (File Encryption Key), которым шифруется само содержимое файла (при помощи какого-нибудь симметричного алгоритма DES/3DES/AES).
  3. Берётся сертификат EFS пользователя и открытым ключом шифруется этот самый FEK, но уже при использовании асимметричного алгоритма.
  4. Зашифрованный ключ кладётся в поле DDF (Data Decryption Field).
  5. Если назначены агенты восстановления файлов EFS, шаги 2 и 3 повторяются для каждого агента восстановления.
  6. Эти зашифрованные ключи кладутся уже в поле DRF (Data Recovery Field).

Предположим, что на данном компьютере работает ещё один пользователь и ему необходимо иметь доступ к файлу. Для этого ему должны быть назначены права чтения на уровне прав NTFS. Но этого недостаточно, поскольку данные зашифрованы. Предоставить файл в общий доступ с другими пользователями может только тот, кто зашифровал файл или агенты восстановления. Для этого пользователь имеющий доступ к зашифрованным данным (владелец) выбирает свойства файла, жмёт Advanced –> Details. Там он увидит список всех пользователей и агентов восстановления, которые могут читать файл. И в этом окошке он может добавить новых пользователей, нажав кнопку Add:

image

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

По умолчанию диалоговое окно показывает сертификаты тех пользователей, чьи сертификаты установлены в контейнере Trusted People локального компьютера. Вы можете выбрать какой-то из них и тогда для этого сертификата повторяются шаги 3-4. Т.е. образуется новое DDF с новым сертификатом и ключ FEK шифруется открытым ключом выбранного сертификата. И владелец этого сертификата (и связанного с ним закрытого ключа) сможет получить доступ к зашифрованному файлу. Всё очень просто.

Примечание: этим окошком категорически запрещается пользоваться в доменной среде! Добавлять пользователя необходимо только через поиск по Active Directory!

Если же пользователь, которому нужен доступ к файлу (предполагается, что файл будет ему передан на съёмном носителе. Никаких доступов по сети) работает на другом компьютере, нажимаете кнопку Find User… и поиском по Active Directory ищите нужного пользователя. Там же будут показаны доступные сертификаты удалённого пользователя.

Если вы внимательно прочитали предыдущую статью, значит вы знаете, что тот же самый процесс происходит и с файлами в сетевой папке, с той лишь разницей, что все сертификаты и криптографические операции производятся на удалённой машине. Т.е. когда вы шифруете файл в сетевой папке, ваш профиль загружается на удалённой машине. Когда вы добавляете пользователя в доступ к шифрованному файлу, убедитесь, что у пользователя на этом удалённом сервере есть свой сертификат EFS (если нету Credential Roaming Service) или они имеют доступ к закрытому ключу от сертификата, который вы будете добавлять в общий доступ. И именно поэтому вам нельзя пользоваться сертификатами из первого окошка, которое вылезает при нажатии кнопки Add. Ведь сертификаты шифрования пользователей находятся на удалённом сервере, а в окошке сертификаты с локального компьютера.

Вывод: при назначении общего доступа к сетевой папке (я так понимаю, что это просто расшаривание ресурса) ничего автоматически не расшифровывается. Даже при предоставлении общего доступа к зашифрованному файлу, т.к. в этом случае расшифровывается только FEK. Но не для подтверждения очевидного я тут распинался пол статьи. Я просто хотел показать тот кромешный ад, который вас ожидает при использовании EFS в масштабах предприятия. И если вы до сих пор не понимаете, как именно происходит весь процесс — не вздумайте даже приближаться к этой теме. Если вы всё поняли — you are welcome!

EFS Recovery agent

Ещё одна вещь, которую многие упускают. По умолчанию, как только зашифрован первый файл в домене, на первом контроллере домена (на котором создавался домен) в профиле первого администратора домена создаётся автоматический сертификат агента восстановления EFS. Этот же сертификат добавляется в Default Domain Policy. Поскольку контроллеры домена относительно часто меняются, риск потерять возможность восстановить зашифрованные файлы ~99,99%.

Более опытные и головастые администраторы у локального CA запрашивают себе отдельный сертификат агента восстановления EFS. Правда, часть из них забывают открытую часть этого сертификата доставить в групповую политику. Или забывают экспортировать его куда-то на съёмный носитель (а лучше два) вместе с ключевой парой на случай смены профиля. По умолчанию, шаблон агента восстановления рассчитан на срок 5 лет. За это время вы обязательно забудете его обновить и результат будет немного предсказуем.

Следовательно, это будет хорошей практикой создать самоподписанный сертификат, который будет действителен лет 20 с самым жирным ключом (например, 4096 бит), экспортировать его в PFX, сложить на 2 флешки (и они не должны храниться в одном месте) и заныкать их. Сертификат агента восстановления доставить в групповую политику в качестве агента восстановления и в Trusted Root CAs (потому что сертификат агента восстановления жёстко проверяется на валидность и если проверка будет провалена, шифрование не произойдёт). Но, это не единственное правильное решение. Вы можете сгенерировать несколько самоподписанных сертификатов и раздать их пользователям, которые будут выполнять функции агента восстановления.

Security |  PKI |  EFS
Monday, May 28, 2012 9:34:00 PM (FLE Daylight Time, UTC+03:00)   Comments [0]    

 

В заключительной части этой беседы мы поговорим об удалении и создании конфигураций отзыва для Online Responder.

Если так случилось, что вам какая-то конфигурация надоела или показалась скучной, вы её можете удалить. Удаляются они при помощи метода DeleteCAConfiguration:

PS C:\> $OCSPAdmin = New-Object -ComObject CertAdm.OCSPAdmin PS C:\> $OCSPAdmin.GetConfiguration("dc2",$true) PS C:\> $OCSPAdmin.OCSPCAConfigurationCollection | %{$_.Identifier} ocsp PS C:\> $OCSPAdmin.OCSPCAConfigurationCollection.DeleteCAConfiguration("ocsp") PS C:\> $OCSPAdmin.SetConfiguration("dc2",$true) PS C:\>

В качестве аргумента указываем название конфигурации (свойство Identifier). И ещё раз напоминаю, что любые изменения необходимо завершать вызовом метода SetConfiguration.

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

Если мы создаём конфигурацию для Enterprise CA:

  1. название новой конфигурации;
  2. сертификат CA;
  3. адрес CA, у которого запрашивать сертификат (адрес указывается в формате: CaHostName\CAName);
  4. шаблон сертификатов, на основе которого будет запрашиваться сертификат подписи;
  5. флаги подписи и энроллмента сертификата подписи;
  6. ссылки на CRL'ы.

Подразумевается, что вы настроили права на шаблон и права на закрытый ключ (Network Service — Allow Read).

Если мы создаём конфигурацию для Standalone CA и/или для CA, который не является членом текущего леса Active Directory:

  1. название новой конфигурации;
  2. сертификат CA;
  3. Флаги подписи;
  4. сертификат подписи;
  5. ссылки на CRL'ы.

В этом случае вы самостоятельно должны доставить сертификат подписи в хранилище сертификатов и назначить права на чтение закрытого ключа для Network Service.

Новая конфигурация создаётся при помощи метода CreateCAConfiguration:

PS C:\> ipmo pspki PS C:\> $cert = (Get-CA dc2*).Certificate PS C:\> $cert Thumbprint Subject ---------- ------- E45ACBB4417260A622C9C45F4322C377A98BEC9D CN=contoso-DC2-CA, DC=contoso, DC=com PS C:\> $Config = $OCSPAdmin.OCSPCAConfigurationCollection.CreateCAConfiguration("Нескучная конфигурация для contoso-dc2 -ca",$cert.RawData) PS C:\> $config Identifier : Нескучная конфигурация для contoso-dc2-ca CACertificate : {48, 130, 4, 78...} HashAlgorithm : SigningFlags : SigningCertificate : ReminderDuration : ErrorCode : 2147483658 CSPName : KeySpec : ProviderCLSID : ProviderProperties : Modified : True LocalRevocationInformation : SigningCertificateTemplate : CAConfig : PS C:\>

Примечание: командлеты Get-CA и Get-ErrorMessage (ниже) доступны только при использовании моего пошпки модуля: http://pspki.codeplex.com/

Как видите, у нас тут толком ничего нету, кроме названия, сертификата CA и ErrorCode. Но ничего страшного, потому что:

PS C:\> "{0:x2}" -f 2147483658 8000000a PS C:\> Get-ErrorMessage 0x8000000a The data necessary to complete this operation is not yet available. PS C:\>

Код указывает нам, что кое какой информации не хватает. Итак, начинаем заполнять свойства. Но, прежде, надо разобраться со свойством SigningFlags. Оно представляет собой сумму комбинаций, которые перечислены здесь: IOCSPCAConfiguration::SigningFlags property. Заранее скажу, что для Enterprise CA нам необходимы следующие флаги:

  • OCSP_SF_ALLOW_SIGNINGCERT_AUTOENROLLMENT — позволяет автоматически запрашивать сертификат подписи, когда предыдущий начнёт истекать;
  • OCSP_SF_RESPONDER_ID_KEYHASH — Online Responder будет себя идентифицировать по KeyID (хешу открытого ключа сертификата CA), а не по имени;
  • OCSP_SF_AUTODISCOVER_SIGNINGCERT — Online Responder будет автоматически выбирать сертификат подписи из хранилища;
  • OCSP_SF_FORCE_SIGNINGCERT_ISSUER_ISCA — сервер сертификации должен подписать сертификат подписи (т.е. не самоподписанный);
  • OCSP_SF_ALLOW_SIGNINGCERT_AUTORENEWAL — Online Responder будет автоматически назначать обновлённый сертификат подписи;
  • OCSP_SF_SILENT — всё должно проходить тихо, без пыли, без дыма и шума.

Если все эти флажки сложить, то должно получиться что-то вроде 605 или около того. Так и запишем:

PS C:\> $Config.SigningFlags = 605 PS C:\> # указываем алгоритм хеширования и подписи PS C:\> $Config.HashAlgorithm = "SHA1" PS C:\> # указываем по истечении какого времени необходимо обновлять сертификат подписи. По умолчанию - 90% PS C:\> $Config.ReminderDuration = 90 PS C:\> # указываем GUID провайдера отзыва: PS C:\> $Config.ProviderCLSID = "{4956d17f-88fd-4198-b287-1e6e65883b19}" PS C:\> # указываем адрес сервера CA, у которого будем получать сертификаты подписи: PS C:\> $Config.CAConfig = "dc2.contoso.com\contoso-dc2-ca" PS C:\> $Config.SigningCertificateTemplate = "OCSPResponseSigning" PS C:\> $Config Identifier : Нескучная конфигурация для contoso-dc2-ca CACertificate : {48, 130, 4, 78...} HashAlgorithm : SHA1 SigningFlags : 605 SigningCertificate : ReminderDuration : 90 ErrorCode : 2147483658 CSPName : KeySpec : ProviderCLSID : {4956d17f-88fd-4198-b287-1e6e65883b19} ProviderProperties : Modified : True LocalRevocationInformation : SigningCertificateTemplate : OCSPResponseSigning CAConfig : dc2.contoso.com\contoso-dc2-ca PS C:\>

Примечание: в теории, Microsoft Online Responder может поддерживать различные типы провайдеров отзыва. Например, как-то лазить в БД самого CA и оттуда извлекать информацию о статусе запрашиваемого сертификата (например, как это делает Tumbleweed OCSP Responder). Поэтому каждому типу провайдера назначется уникальный GUID. На практике я не очень представляю, как это можно расширить и мы будем использовать CRL-based провайдер. И для него GUID всегда должен быть 4956d17f-88fd-4198-b287-1e6e65883b19.

CSP и KeySpec указывать не надо, потому что эта информация хранится в шаблоне сертификата. Теперь нам надо нстроить провайдер отзыва. По большому счёту, достаточно указать только ссылки на Base и Delta (если надо) CRL. Конфигурация отзыва создаётся при помощи интерфейса IOCSPPropertyCollection:

$OCSPPropCollection = New-Object -ComObject CertAdm.OCSPPropertyCollection
[void]$OCSPPropCollection.InitializeFromProperties($null)
# для получения ссылок на BaseCRL можно использовать ICertAdmin и CR_PROP_CERTCDPURLS (0x29)
$CertAdmin = New-Object -ComObject CertificateAuthority.Admin
$BaseCRLURLs = $CertAdmin.GetCAProperty("dc2\contoso-dc2-ca",0x29,0,4,0).split("`n", [StringSplitOptions]::RemoveEmptyEntries)
[void]$OCSPPropCollection.CreateProperty("BaseCrlUrls",[String[]]$BaseCRLURLs)
# ссылки на DeltaCRL надо вбивать/преобразовывать вручную.
$DeltaCRLURLs = $BaseCRLURLs | %{
    if ($_ -match "^http") {
        $_ -replace "\.crl$", "+.crl"
    } else {
        $_ -replace "\?certificateRevocationList\?","?deltaRevocationList?"
    }
}
[void]$OCSPPropCollection.CreateProperty("DeltaCrlUrls",[String[]]$DeltaCRLURLs)
# записываем свойства провайдера отзыва в нашу конфигурацию
$Config.ProviderProperties = $OCSPPropCollection.GetAllProperties()

PS C:\> $Config Identifier : Нескучная конфигурация для contoso-dc2-ca CACertificate : {48, 130, 4, 78...} HashAlgorithm : SHA1 SigningFlags : 605 SigningCertificate : ReminderDuration : 90 ErrorCode : 2147483658 CSPName : KeySpec : ProviderCLSID : {4956d17f-88fd-4198-b287-1e6e65883b19} ProviderProperties : {BaseCrlUrls, http://www.contoso.com/pki/contoso-DC2-CA.crl, DeltaCrlUrls, http://www.cont oso.com/pki/contoso-DC2-CA+.crl} Modified : True LocalRevocationInformation : SigningCertificateTemplate : OCSPResponseSigning CAConfig : dc2.contoso.com\contoso-dc2-ca PS C:\> $OCSPAdmin.SetConfiguration("dc2",$true) PS C:\>

И, собственно, результаты наших трудов в UI:

Online Responder revocation configuration UI

Профит получен. Вот так, нехитрым способом можно автоматизировать создание конфигураций для Online Responder.

з.ы. в ближайшее время я планирую доставить очередную версию пошпкимодуля и там будет целый набор классов .NET, которые позволяют проверить работоспособность и правильность настройки респондера (путём отправки запроса и декодированием ответа) в соответствии с RFC2560. Так что ждите анонсов.

Monday, May 21, 2012 9:35:02 PM (FLE Daylight Time, UTC+03:00)   Comments [0]    

 

«Older Posts  · 

All content © 2008 - 2014, Vadims Podāns
"Spaces" Theme provided by: Vadims Podāns
About


E-mail - Send mail to the author(s)
Live Messenger -
For english language visitors
Библиотека
Календарик
<November 2014>
SunMonTueWedThuFriSat
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

Карта расположения посетителей
Favorites





Fan list



Disclaimer
Вся информация на сайте предоставляется на условиях «как есть», без предоставления каких-либо гарантий и прав.

При использовании материалов c данного сайта ссылка на оригинальный источник обязательна.
Protected by Copyscape Online Plagiarism Scanner