Linux-Bulgaria.ORG
навигация

 

начало

пощенски списък

архив на групата

семинари ...

документи

как да ...

 

 

Предишно писмо Следващо писмо Предишно по тема Следващо по тема По Дата По тема (thread)

Re: lug-bg: Certificate chain of 3-4 levels


  • Subject: Re: lug-bg: Certificate chain of 3-4 levels
  • From: Vesselin Kolev <vlk@xxxxxxxxxxxxxxxxx>
  • Date: Mon, 21 Feb 2005 13:39:28 +0200

Vesselin Kolev wrote:

За да можеш да подписваш сертификат с вече подписан от CA сертификат, в сертификата, с който ще удостоверяваш направения от теб подпис (който съдържа публичния ключ, комплементарен към частния ти) трябва да имаш поле (X.509 идентификатор) CA:TRUE и това поле да е подписано от издателя на твоя сертификат (това е транзитивност на доверието). Това те прави подудостоверител. Голяма рядкост е някой официален удостоверител да издаде подобен сертификат на някого, защото така все едно го упълномощава да подписва от негово име.

Всъщност, за да стане по-ясно, има два вида удостоверителски сертификати: самоподписани и делегирани.

1) Самоподписан удостоверителски сертификат е винаги върха на пирамидата на доверие в модела X.509 и там полето CA:TRUE е самоподписано (както и другите полета). 2) Делегиран удостоверителски сертификат се издава на подудостоверител и при него нямаме самодписан сертификат, но имаме подписване на полето CA:TRUE от удостоверител, който стои по-горе във веригата на удостоверяване.

Когато удостоверяваш един сертификат подписан от подудостоверител, трябва да подаваш цялата вертификатна верига към клиента: от първия подудостоверител до последния, плюс конкретния подписан от последния сертифкат:)

Ако искаш по-подробно обяснение и това не е ясно... питай тук или си уговори частен разговор с мен за да ти покажа как действа подобна, създадена от мен йерархия.

Поздравви
   Весо

Ще допълня себе си за да остане това нещо в архива и да улесним питащите. А и информацията по темата в Интернет не е никак изчерпателна.

Както казах и по-горе, в сертификатния модел X.509 съществуват два вида удостоверители: първични и делегирани (подудостоверители).


Описание на първичен удостоверител.

Това е удостоверител, който сам си гласува доверие. Това той прави като си издаде самоподписан сертификат. Ето пример за самоподписан X.509 сертификат, който дава начало на пирамидата на доверие:

Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number: 0 (0x0)
       Signature Algorithm: sha1WithRSAEncryption
       Issuer: C=BG, ST=Sofia, L=Sofia, O=OpenIntegra Ltd., OU=OpenIntegra Certificate Authority, CN=OpenIntegra Root Certificate/emailAddress=ca@xxxxxxxxxxxxxxx
       Validity
           Not Before: Oct  7 12:12:44 2003 GMT
           Not After : Oct  5 12:12:44 2011 GMT
       Subject: C=BG, ST=Sofia, L=Sofia, O=OpenIntegra Ltd., OU=OpenIntegra Certificate Authority, CN=OpenIntegra Root Certificate/emailAddress=ca@xxxxxxxxxxxxxxx
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (4096 bit)
               Modulus (4096 bit):
                   00:9b:95:d7:04:02:7b:b5:07:38:3c:94:de:ad:3a:
                   ...
                   ee:e1:61
               Exponent: 65537 (0x10001)
       X509v3 extensions:
X509v3 Subject Key Identifier: C7:F7:B1:DE:9C:EC:34:75:3C:E7:20:E6:40:60:4F:57:1E:F3:29:0C X509v3 Authority Key Identifier: keyid:C7:F7:B1:DE:9C:EC:34:75:3C:E7:20:E6:40:60:4F:57:1E:F3:29:0C
           DirName:/C=BG/ST=Sofia/L=Sofia/O=OpenIntegra Ltd./OU=OpenIntegra Certificate Authority/CN=OpenIntegra Root Certificate/emailAddress=ca@xxxxxxxxxxxxxxx
           serial:00

           X509v3 Basic Constraints: critical
           CA:TRUE
X509v3 Key Usage: Certificate Sign, CRL Sign
   Signature Algorithm: sha1WithRSAEncryption
       4c:cc:fe:85:67:4c:67:27:89:d8:9b:ad:35:01:92:c0:1b:75:
       ...
       97:90:ef:d9:e4:85:a6:2c


Самоподписването се изразява в това, че издателя:

Issuer: C=BG, ST=Sofia, L=Sofia, O=OpenIntegra Ltd., OU=OpenIntegra Certificate Authority, CN=OpenIntegra Root Certificate/emailAddress=ca@xxxxxxxxxxxxxxx

и удостоверявания обект:

Subject: C=BG, ST=Sofia, L=Sofia, O=OpenIntegra Ltd., OU=OpenIntegra Certificate Authority, CN=OpenIntegra Root Certificate/emailAddress=ca@xxxxxxxxxxxxxxx

са един и същи. След като се генерира двойката частен/публичен ключ се генерира и заявка, а тази заявка се подписва с частния ключ от двойката. Така се създава самоподписването.

Това, което прави сертификата удостоверителски е наличието на едно това поле:

CA:TRUE

То ясно се вижда в горния пример.

Нека обобщим: върха на пирамидата на доверие е сертификата на удостоверителя, той е самоподписан (Issuer=Subject) и съдържа полето CA:TRUE.


Описание на подудостоверител.

Това е удостоверител, на който се гласува доверие поради това, че някой друг му е дал доверие и този друг стои някъде по-горе в йерархията на доверие.

Ето примерен сертификат:

Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number: 2 (0x2)
       Signature Algorithm: sha1WithRSAEncryption
       Issuer: C=BG, ST=Sofia, L=Sofia, O=OpenIntegra Ltd., OU=OpenIntegra Certificate Authority, CN=OpenIntegra Root Certificate/emailAddress=ca@xxxxxxxxxxxxxxx
       Validity
           Not Before: Oct  7 12:58:16 2003 GMT
           Not After : Oct  5 12:58:16 2011 GMT
       Subject: C=BG, ST=Sofia, L=Sofia, O=OpenIntegra Ltd., OU=OpenIntegra Certificate Authority, CN=OpenIntegra Certificate for Server Signing/emailAddress=ca@xxxxxxxxxxxxxxx
       Subject Public Key Info:
           Public Key Algorithm: rsaEncryption
           RSA Public Key: (4096 bit)
               Modulus (4096 bit):
                   00:9e:58:aa:71:82:61:5d:b9:c9:de:d4:05:cb:f0:
                   ...
                   68:e5:f1
               Exponent: 65537 (0x10001)
       X509v3 extensions:
           X509v3 Basic Constraints: critical
           CA:TRUE
Netscape Comment: OpenIntegra Certificate X509v3 Subject Key Identifier: 8E:FD:BA:18:8D:87:63:D7:09:07:08:FA:C8:91:4E:68:74:49:20:A5 X509v3 Authority Key Identifier: keyid:C7:F7:B1:DE:9C:EC:34:75:3C:E7:20:E6:40:60:4F:57:1E:F3:29:0C
           DirName:/C=BG/ST=Sofia/L=Sofia/O=OpenIntegra Ltd./OU=OpenIntegra Certificate Authority/CN=OpenIntegra Root Certificate/emailAddress=ca@xxxxxxxxxxxxxxx
           serial:00

   Signature Algorithm: sha1WithRSAEncryption
       9a:cf:5f:95:4d:00:5e:82:47:ae:a1:08:51:c1:c0:4d:15:9c:
       ...
       ec:7c:4d:ff:33:9f:e5:d0


Особеностите са следните. За разлика от самоподписания сертификат, тук заявителя и издателя на сертификата са различни субекти (и притежават различни двойки частен/публичен ключ). Заявителя издава заявка и я праща към по-горестоящия удостоверител. Той я подписва, като подписва и полето

CA: TRUE

което се вижда по-горе. Така удостоверителя прави заявителя удостоверител и прибавя едно ниво надолу в йерархията на удостоверителите.


Сега малко за "depth". Този параметър отчита доколко дълбоко стигат поудостоверителските услуги (т.е. колко подустоверителя има под върховния удостоверител, който има самоподписан сертификат). Пита се за какво се използва тази величина "depth". Тази величина може да се използва при доверяване на някоя услуга на дадена пирамида на доверие. Примерно Apache/mod_ssl дефинира до каква дълбочина на удостоверяване може да вярва на дадена пирамида за удостоверяване. Разумен е въпроса защо се прави това. Истината е, че колкото по-голяма е стойността на параметъра "depth", толкова повече имаме "размиване" на доверието. Това ще рече, че имаме повече звена, които биха могли да бъдат атакувани и следователно схемата на доверие някъде би могла да бъде взломена.


Когато се използва "depth" трябва да се подава сертификатната верига. Какво значи това? Давам пример за Apache/mod_ssl. Имаме следната верига на доверие:

CA --> SubCA(1) --> SubCA(2) --> Client

Пита се каква верига трябва да подаде Apache на клиента. Истината е, че клиента не трябва да има в своето сертификатно хранилище сертификатите на SubCA(1) и SubCA(2). Той трябва да има само сертификата на CA. Apache има грижата да му подаде следната верига:

SubCA(1) --> SubCA(2) --> Client

и клиента да ще я валидира благодарение на това, че разполага с CA сертификата.

Конкретно в конфигурационния файл на Apache се използва директивата:

SSLCertificateChainFile  /path/to/chain/file

и в указания файл се поставят сертификатите на SubCA(1) и SubCA(2)

Клиентския сертификат се указва с

SSLCertificateFile /path/to/cert/file


Сега клиента запитва Apache и той му дава съдържанието на SSLCertificateChainFile плюс съдържанието на SSLCertificateFile. След като клиента има CA сертификата валидира веригата.

Честа грешка, която се прави е да не се подава веригата. И после следват чуденки защо клиента не може да валидира сертификата на сървъра.


Сега обратната ситуация. Клиент се удостоверява пред Apache сървъра с клиентски сертификат. Клиента подава също веригата на своя сертификат (разбира се, ако използва схема с подудостоверители). Администратора на Apache избира дълбочината "depth" на доверието:

SSLVerifyDepth  тук_стои_число

Ако сертификата принадлежи на верига с по-голяма дълбочина от описаната, той се отхвърля.



Това е

 Поздрави
    Весо



============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================



 

наши приятели

 

линукс за българи
http://linux-bg.org

FSA-BG
http://fsa-bg.org

OpenFest
http://openfest.org

FreeBSD BG
http://bg-freebsd.org

KDE-BG
http://kde.fsa-bg.org/

Gnome-BG
http://gnome.cult.bg/

проект OpenFMI
http://openfmi.net

NetField Forum
http://netField.ludost.net/forum/

 

 

Linux-Bulgaria.ORG

Mailing list messages are © Copyright their authors.