от Bondoff(21-02-2005)

рейтинг (14)   [ добре ]  [ зле ]

Printer Friendly Вариант за отпечатване

Тест на инсталацията

След като сме инсталирали уеб сървър Apache 2, конфигурирали сме настройките на SSL, създали сме self-signed сертификат, както и тестова уеб страница – време е да тестваме конфигурацията си:

/usr/local/apache2/bin/apachectl startssl
 Apache/2.0.52 mod_ssl/2.0.52 (Pass Phrase Dialog)
 Some of your private key files are encrypted for security reasons.
 In order to read them you have to provide us with the pass phrases.
 
 Server 127.0.0.1:443 (RSA)
 Enter pass phrase:*************
 
 Ok: Pass Phrase Dialog successful.

След като стартираме сървъра трябва да се опитаме да извършим конекция към него, като естествено му укажем, че бихме желали връзката към него да минава през криптиран “тунел”.

Елементарно – уеб браузер и въвеждаме https://name.of.the.web.server (в посочения пример https://www.seccure.lab)

Първото, което ще видите (след като натиснете Enter) е Warning Message на браузера, което ви информира за това, че има проблем при автентикацията на уеб сървъра, до който искаме да достигнем.

В следващата фигура е показан пример с MS Internet Explorer 6.0.

Figure 3.


Напълно нормално. Този прозорец се появава защото:

  • Сертификата на уеб сървъра не е подписан от root CA или друг достоверен CA съръвр;

  • И второ - CN (Common Name) атрибута на сертификата НЕ отговаря на името на уеб сайта. Ако сте обърнали внимание в Част II на статията, при създаването на сертификата зададохме стойност "Test-Only Certificate". За CN е прието да се задава FQDN (Fully Qualified Domain Name) – пълното домейн име на сайта (в примера www.seccure.lab)

За сега ще натиснем бутона Yes и ако всичко останало е наред би трябвало да видите следващия екран:

Figure 4.


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

Ако кликнете два пъти върху “катинарчето” ще видите детайлна информация за сертификата на уеб сървъра, както е показано:

Figure 5.


Troubleshooting (което обикновенно се превежда като “производствена авария”)

Ако по някаква причина не може да достигнете до уеб сайта, има един добър инструмен, който се казва "s_client" и е включен билиотеките на OpenSSL. С помощта на s_client може да извършите диагностика на TLS/SSL конекцията. В примера е показано как става това:

/usr/bin/openssl s_client -connect localhost:443
   CONNECTED(00000003)
   depth=0 /CN=Test-Only Certificate
   verify error:num=18:self signed certificate
   verify return:1
   depth=0 /CN=Test-Only Certificate
   verify return:1
   ---
   Certificate chain
    0 s:/CN=Test-Only Certificate
      i:/CN=Test-Only Certificate
   ---
   Server certificate
   -----BEGIN CERTIFICATE-----
   MIICLzCCAZigAwIBAgIBADANBgkqhkiG9w0BAQQFADAgMR4wHAYDVQQDExVUZXN0
   LU9ubHkgQ2VydGlmaWNhdGUwHhcNMDQxMTIyMTg0ODUxWhcNMDQxMjIyMTg0ODUx
   WjAgMR4wHAYDVQQDExVUZXN0LU9ubHkgQ2VydGlmaWNhdGUwgZ8wDQYJKoZIhvcN
   AQEBBQADgY0AMIGJAoGBAMEttnihJ7JpksdToPi5ZVGcssUbHn/G+4G43OiLhP0i
   KvYuqNxBkSqqM1AanR0BFVEtVCSuq8KS9LLRdQLJ/B1UTMOGz1Pb14WGsVJS+38D
   LdLEFaCyfkjNKnUgeKMyzsdhZ52pF9febB+d8cLmvXFve28sTIxLCUK7l4rjT3Xl
 
   AgMBAAGjeTB3MB0GA1UdDgQWBBQ50isUEV6uFPZ0L4RbRm41+i1CpTBIBgNVHSME
   QTA/gBQ50isUEV6uFPZ0L4RbRm41+i1CpaEkpCIwIDEeMBwGA1UEAxMVVGVzdC1P
   bmx5IENlcnRpZmljYXRlggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQAD
   gYEAThyofbK3hg8AJXbAUD6w6+mz6dwsBmcTWLvYtLQUh86B0zWnVxzSLDmwgdUB
   NxfJ7yfo0PkqNnjHfvnb5W07GcfGgLx5/U3iUROObYlwKlr6tQzMoysNQ/YtN3pp
   52sGsqaOOWpYlAGOaM8j57Nv/eXogQnDRT0txXqoVEbunmM=
   -----END CERTIFICATE-----
   subject=/CN=Test-Only Certificate
   issuer=/CN=Test-Only Certificate
   ---
   No client certificate CA names sent
   ---
   SSL handshake has read 1143 bytes and written 362 bytes
   ---
   New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
   Server public key is 1024 bit
   SSL-Session:
       Protocol  : SSLv3
       Cipher    : DHE-RSA-AES256-SHA
       Session-ID: 56EA68A5750511917CC42A1B134A8F218C27C9C0241C35C53977A2A8BBB9986A
       Session-ID-ctx:
       Master-Key: 303B60D625B020280F5F346AB00F8A61A7C4BEA707DFA0ED8D2F52371F8C4F087FB6EFFC02CE3B48F912D2C8929DB5BE
       Key-Arg   : None
       Start Time: 1101164382
       Timeout   : 300 (sec)
       Verify return code: 18 (self signed certificate)
   ---
   GET / HTTP/1.0
 
   HTTP/1.1 200 OK
   Date: Mon, 22 Nov 2004 22:59:56 GMT
   Server: Apache
   Last-Modified: Mon, 22 Nov 2004 17:24:56 GMT
   ETag: "5c911-46-229c0a00"
   Accept-Ranges: bytes
   Content-Length: 70
   Connection: close
   Content-Type: text/html
 
   TestTest works.
   closed



s_client има доста полезни опции, като например включване/изключване поддръжката на протоколи (-ssl2, -ssl3, -tls1), използване на сигурен шифър (-cipher), установяване в режим debug (-debug), следене на състоянието и съобщенията на SSL/TLS конекцията (-state, -msg), както и някои други опции които може да видите в хелпа на s_client, и които може да ви бъдат полезни.

Ако с помощта на s_client не успеете да откриете проблема, ще трябва да промените стойността на LogLevel (в httpd.conf) на "debug", рестартирайте Apache и след това проверете логовете (/usr/local/apache2/logs/) за повече информация.

Може също така да опитате и с някои други инструменти, като например Ethereal или ssldump. Благодарение на тези инструменти, може пасивно да наблюдавате SSL-ръкостискане (SSL Handshake) и евентуално да разберете каква е причината за проблема. На следващата фигура може да видите скрийншот на SSL ръкостискане наблюдавано с Ethereal.

Figure 6.


Искреното ми желание беше тази част на статията да бъде последна, но се оказа, че не съм преценил правилно разпределението на материала и ако всичко бъде публикувано тук, има опасност тази част да стане досадно дълга и трудна за четене. Благодаря на читателите за критиките и коментарите на първите две части! Предварително благодаря и за търпението Ви!

В последната част (обещавам да е последна) ще видите “обещаните” препоръчителни настройки, а също така (лични благодарности на Весо) ще засегнем и темата за сертификатите, получаване на сертификат от достоверен CA сървър, както и възможност за получаване на сертификат от локален CA.





<< Как да използваме dmix в alsa | Стъпка по стъпка: Apache 2 с поддръжка на SSL/TLS. Част I >>