From 2faa747e2303ee774a4b4aace961188e950e185a Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Mon, 8 Apr 2024 21:09:22 +0200 Subject: Adding upstream version 2.4.58. Signed-off-by: Daniel Baumann --- docs/manual/ssl/index.html | 21 + docs/manual/ssl/index.html.en | 71 +++ docs/manual/ssl/index.html.fr.utf8 | 73 +++ docs/manual/ssl/index.html.ja.utf8 | 72 +++ docs/manual/ssl/index.html.tr.utf8 | 71 +++ docs/manual/ssl/index.html.zh-cn.utf8 | 72 +++ docs/manual/ssl/ssl_compat.html | 9 + docs/manual/ssl/ssl_compat.html.en | 248 ++++++++ docs/manual/ssl/ssl_compat.html.fr.utf8 | 257 ++++++++ docs/manual/ssl/ssl_faq.html | 9 + docs/manual/ssl/ssl_faq.html.en | 935 ++++++++++++++++++++++++++++ docs/manual/ssl/ssl_faq.html.fr.utf8 | 1036 +++++++++++++++++++++++++++++++ docs/manual/ssl/ssl_howto.html | 9 + docs/manual/ssl/ssl_howto.html.en | 449 ++++++++++++++ docs/manual/ssl/ssl_howto.html.fr.utf8 | 489 +++++++++++++++ docs/manual/ssl/ssl_intro.html | 13 + docs/manual/ssl/ssl_intro.html.en | 672 ++++++++++++++++++++ docs/manual/ssl/ssl_intro.html.fr.utf8 | 727 ++++++++++++++++++++++ docs/manual/ssl/ssl_intro.html.ja.utf8 | 730 ++++++++++++++++++++++ 19 files changed, 5963 insertions(+) create mode 100644 docs/manual/ssl/index.html create mode 100644 docs/manual/ssl/index.html.en create mode 100644 docs/manual/ssl/index.html.fr.utf8 create mode 100644 docs/manual/ssl/index.html.ja.utf8 create mode 100644 docs/manual/ssl/index.html.tr.utf8 create mode 100644 docs/manual/ssl/index.html.zh-cn.utf8 create mode 100644 docs/manual/ssl/ssl_compat.html create mode 100644 docs/manual/ssl/ssl_compat.html.en create mode 100644 docs/manual/ssl/ssl_compat.html.fr.utf8 create mode 100644 docs/manual/ssl/ssl_faq.html create mode 100644 docs/manual/ssl/ssl_faq.html.en create mode 100644 docs/manual/ssl/ssl_faq.html.fr.utf8 create mode 100644 docs/manual/ssl/ssl_howto.html create mode 100644 docs/manual/ssl/ssl_howto.html.en create mode 100644 docs/manual/ssl/ssl_howto.html.fr.utf8 create mode 100644 docs/manual/ssl/ssl_intro.html create mode 100644 docs/manual/ssl/ssl_intro.html.en create mode 100644 docs/manual/ssl/ssl_intro.html.fr.utf8 create mode 100644 docs/manual/ssl/ssl_intro.html.ja.utf8 (limited to 'docs/manual/ssl') diff --git a/docs/manual/ssl/index.html b/docs/manual/ssl/index.html new file mode 100644 index 0000000..45c7bc7 --- /dev/null +++ b/docs/manual/ssl/index.html @@ -0,0 +1,21 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: index.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: index.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: index.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: index.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 + +URI: index.html.zh-cn.utf8 +Content-Language: zh-cn +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/ssl/index.html.en b/docs/manual/ssl/index.html.en new file mode 100644 index 0000000..50113c0 --- /dev/null +++ b/docs/manual/ssl/index.html.en @@ -0,0 +1,71 @@ + + + + + +Apache SSL/TLS Encryption - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Apache SSL/TLS Encryption

+
+

Available Languages:  en  | + fr  | + ja  | + tr  | + zh-cn 

+
+ +

The Apache HTTP Server module mod_ssl +provides an interface to the OpenSSL library, which provides +Strong Encryption using the Secure Sockets Layer and Transport Layer +Security protocols.

+
+ +
top
+
+

Documentation

+ +
top
+
+

mod_ssl

+

Extensive documentation on the directives and environment variables +provided by this module is provided in the mod_ssl reference documentation. +

+
+
+

Available Languages:  en  | + fr  | + ja  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/ssl/index.html.fr.utf8 b/docs/manual/ssl/index.html.fr.utf8 new file mode 100644 index 0000000..e43563d --- /dev/null +++ b/docs/manual/ssl/index.html.fr.utf8 @@ -0,0 +1,73 @@ + + + + + +Apache et le Chiffrement SSL/TLS - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Apache et le Chiffrement SSL/TLS

+
+

Langues Disponibles:  en  | + fr  | + ja  | + tr  | + zh-cn 

+
+ +

Le module mod_ssl du serveur HTTP Apache fournit une +interface avec la bibliothèque OpenSSL, qui permet d'effectuer un +chiffrement fort en s'appuyant sur les protocoles "Couche Points d'accès +Sécurisés" (Secure Sockets Layer - SSL) et "Sécurité de la Couche Transport" +(Transport Layer Security - TLS).

+
+ +
top
+
+

Documentation

+ +
top
+
+

mod_ssl

+

La documentation complète sur les directives et les variables +d'environnement fournies par ce module se trouve dans la +documentation de référence de mod_ssl. +

+
+
+

Langues Disponibles:  en  | + fr  | + ja  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/ssl/index.html.ja.utf8 b/docs/manual/ssl/index.html.ja.utf8 new file mode 100644 index 0000000..35b1d7d --- /dev/null +++ b/docs/manual/ssl/index.html.ja.utf8 @@ -0,0 +1,72 @@ + + + + + +Apache の SSL/TLS 暗号化 - Apache HTTP サーバ バージョン 2.4 + + + + + + +
+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

+

Apache HTTP サーバ バージョン 2.4

+
+
<-
+

Apache の SSL/TLS 暗号化

+
+

翻訳済み言語:  en  | + fr  | + ja  | + tr  | + zh-cn 

+
+ +

Apache HTTP サーバモジュール mod_ssl が +OpenSSL +ライブラリへのインターフェースを提供していますが、これは +Secure Sockts Layer と Transport Layer Security +プロトコルを用いた強力な暗号化を提供します。

+
+ +
top
+
+

Documentation

+ +
top
+
+

mod_ssl

+

このモジュールで提供されるディレクティブや環境変数に関する +詳しい文書は、mod_ssl +リファレンスをご覧下さい。

+
+
+

翻訳済み言語:  en  | + fr  | + ja  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/ssl/index.html.tr.utf8 b/docs/manual/ssl/index.html.tr.utf8 new file mode 100644 index 0000000..1555548 --- /dev/null +++ b/docs/manual/ssl/index.html.tr.utf8 @@ -0,0 +1,71 @@ + + + + + +Apache SSL/TLS Şifrelemesi - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + +
+

Modüller | Yönergeler | SSS | Terimler | Site Haritası

+

Apache HTTP Sunucusu Sürüm 2.4

+
+
<-
+

Apache SSL/TLS Şifrelemesi

+
+

Mevcut Diller:  en  | + fr  | + ja  | + tr  | + zh-cn 

+
+ +

Apache HTTP Sunucusunun mod_ssl modülü, Güvenli Soketler + Katmanı (SSL) ve Aktarım Katmanı Güvenliği (TLS) protokollerinin + kullanıldığı Sağlam Şifreleme desteğini sağlayan OpenSSL kütüphanesine bir arayüz + içerir.

+
+ +
top
+
+

Belgeler

+ +
top
+
+

mod_ssl Modülü

+

Bu modülce sağlanan yönergeler ve ortam değişkenleri + mod_ssl başvuru kılavuzunda ayrıntılı olarak + açıklanmıştır.

+
+
+

Mevcut Diller:  en  | + fr  | + ja  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/ssl/index.html.zh-cn.utf8 b/docs/manual/ssl/index.html.zh-cn.utf8 new file mode 100644 index 0000000..c5bab75 --- /dev/null +++ b/docs/manual/ssl/index.html.zh-cn.utf8 @@ -0,0 +1,72 @@ + + + + + +Apache SSL/TLS 加密 - Apache HTTP 服务器 版本 2.4 + + + + + + +
+

模块 | 指令 | 常见问题 | 术语 | 网站导航

+

Apache HTTP 服务器版本 2.4

+
+
<-
+

Apache SSL/TLS 加密

+
+

可用语言:  en  | + fr  | + ja  | + tr  | + zh-cn 

+
+
此翻译可能过期。要了解最近的更改，请阅读英文版。
+ +

Apache HTTP 服务器模块 mod_ssl +提供了与 OpenSSL +的接口，它使用安全套接字层和传输层安全协议提供了强加密。 +此模块与这篇文档都基于 +Ralf S. Engelschall 的 mod_ssl 项目。

+
+ +
top
+
+

文档

+ +
top
+
+

mod_ssl

+

此模块提供的指令和环境变量的文档位于 mod_ssl 参考手册。 +

+
+
+

可用语言:  en  | + fr  | + ja  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/ssl/ssl_compat.html b/docs/manual/ssl/ssl_compat.html new file mode 100644 index 0000000..70a72cb --- /dev/null +++ b/docs/manual/ssl/ssl_compat.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: ssl_compat.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: ssl_compat.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/ssl/ssl_compat.html.en b/docs/manual/ssl/ssl_compat.html.en new file mode 100644 index 0000000..fb1f45f --- /dev/null +++ b/docs/manual/ssl/ssl_compat.html.en @@ -0,0 +1,248 @@ + + + + + +SSL/TLS Strong Encryption: Compatibility - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

SSL/TLS Strong Encryption: Compatibility

+
+

Available Languages:  en  | + fr 

+
+ +

+This page covers backwards compatibility between mod_ssl and other +SSL solutions. mod_ssl is not the only SSL solution for Apache; four +additional products are (or were) also available: Ben Laurie's freely +available Apache-SSL (from +where mod_ssl were originally derived in 1998), Red Hat's commercial +Secure Web Server (which was based on mod_ssl), Covalent's commercial +Raven SSL Module (also based on +mod_ssl) and finally C2Net's (now Red Hat's) commercial product Stronghold (based +on a different evolution branch, named Sioux up to Stronghold 2.x, and +based on mod_ssl since Stronghold 3.x).

+ +

+mod_ssl mostly provides a superset of the functionality of all the other +solutions, so it's simple to migrate from one of the older modules to +mod_ssl. The configuration directives and environment variable names +used by the older SSL solutions vary from those used in mod_ssl; +mapping tables are included here to give the equivalents used by mod_ssl.

+
+ +
top
+
+

Configuration Directives

+

The mapping between configuration directives used by Apache-SSL +1.x and mod_ssl 2.0.x is given in Table +1. The mapping from Sioux 1.x and Stronghold 2.x is only partial +because of special functionality in these interfaces which mod_ssl +doesn't provide.

+ + +

Table 1: Configuration Directive Mapping

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Old Directivemod_ssl DirectiveComment
Apache-SSL 1.x & mod_ssl 2.0.x compatibility:
SSLEnableSSLEngine oncompactified
SSLDisableSSLEngine offcompactified
SSLLogFile fileUse per-module LogLevel setting instead.
SSLRequiredCiphers specSSLCipherSuite specrenamed
SSLRequireCipher c1 ...SSLRequire %{SSL_CIPHER} in {"c1", +...}generalized
SSLBanCipher c1 ...SSLRequire not (%{SSL_CIPHER} in {"c1", +...})generalized
SSLFakeBasicAuthSSLOptions +FakeBasicAuthmerged
SSLCacheServerPath dir-functionality removed
SSLCacheServerPort integer-functionality removed
Apache-SSL 1.x compatibility:
SSLExportClientCertificatesSSLOptions +ExportCertDatamerged
SSLCacheServerRunDir dir-functionality not supported
Sioux 1.x compatibility:
SSL_CertFile fileSSLCertificateFile filerenamed
SSL_KeyFile fileSSLCertificateKeyFile filerenamed
SSL_CipherSuite argSSLCipherSuite argrenamed
SSL_X509VerifyDir argSSLCACertificatePath argrenamed
SSL_Log file-Use per-module LogLevel setting instead.
SSL_Connect flagSSLEngine flagrenamed
SSL_ClientAuth argSSLVerifyClient argrenamed
SSL_X509VerifyDepth argSSLVerifyDepth argrenamed
SSL_FetchKeyPhraseFrom arg-not directly mappable; use SSLPassPhraseDialog
SSL_SessionDir dir-not directly mappable; use SSLSessionCache
SSL_Require expr-not directly mappable; use SSLRequire
SSL_CertFileType arg-functionality not supported
SSL_KeyFileType arg-functionality not supported
SSL_X509VerifyPolicy arg-functionality not supported
SSL_LogX509Attributes arg-functionality not supported
Stronghold 2.x compatibility:
StrongholdAccelerator engineSSLCryptoDevice enginerenamed
StrongholdKey dir-functionality not needed
StrongholdLicenseFile dir-functionality not needed
SSLFlag flagSSLEngine flagrenamed
SSLSessionLockFile fileSSLMutex filerenamed
SSLCipherList specSSLCipherSuite specrenamed
RequireSSLSSLRequireSSLrenamed
SSLErrorFile file-functionality not supported
SSLRoot dir-functionality not supported
SSL_CertificateLogDir dir-functionality not supported
AuthCertDir dir-functionality not supported
SSL_Group name-functionality not supported
SSLProxyMachineCertPath dirSSLProxyMachineCertificatePath dirrenamed
SSLProxyMachineCertFile fileSSLProxyMachineCertificateFile filerenamed
SSLProxyCipherList specSSLProxyCipherSpec specrenamed
+ +
top
+
+

Environment Variables

+ +

The mapping between environment variable names used by the older +SSL solutions and the names used by mod_ssl is given in Table 2.

+ +

Table 2: Environment Variable Derivation

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Old Variablemod_ssl VariableComment
SSL_PROTOCOL_VERSIONSSL_PROTOCOLrenamed
SSLEAY_VERSIONSSL_VERSION_LIBRARYrenamed
HTTPS_SECRETKEYSIZESSL_CIPHER_USEKEYSIZErenamed
HTTPS_KEYSIZESSL_CIPHER_ALGKEYSIZErenamed
HTTPS_CIPHERSSL_CIPHERrenamed
HTTPS_EXPORTSSL_CIPHER_EXPORTrenamed
SSL_SERVER_KEY_SIZESSL_CIPHER_ALGKEYSIZErenamed
SSL_SERVER_CERTIFICATESSL_SERVER_CERTrenamed
SSL_SERVER_CERT_STARTSSL_SERVER_V_STARTrenamed
SSL_SERVER_CERT_ENDSSL_SERVER_V_ENDrenamed
SSL_SERVER_CERT_SERIALSSL_SERVER_M_SERIALrenamed
SSL_SERVER_SIGNATURE_ALGORITHMSSL_SERVER_A_SIGrenamed
SSL_SERVER_DNSSL_SERVER_S_DNrenamed
SSL_SERVER_CNSSL_SERVER_S_DN_CNrenamed
SSL_SERVER_EMAILSSL_SERVER_S_DN_Emailrenamed
SSL_SERVER_OSSL_SERVER_S_DN_Orenamed
SSL_SERVER_OUSSL_SERVER_S_DN_OUrenamed
SSL_SERVER_CSSL_SERVER_S_DN_Crenamed
SSL_SERVER_SPSSL_SERVER_S_DN_SPrenamed
SSL_SERVER_LSSL_SERVER_S_DN_Lrenamed
SSL_SERVER_IDNSSL_SERVER_I_DNrenamed
SSL_SERVER_ICNSSL_SERVER_I_DN_CNrenamed
SSL_SERVER_IEMAILSSL_SERVER_I_DN_Emailrenamed
SSL_SERVER_IOSSL_SERVER_I_DN_Orenamed
SSL_SERVER_IOUSSL_SERVER_I_DN_OUrenamed
SSL_SERVER_ICSSL_SERVER_I_DN_Crenamed
SSL_SERVER_ISPSSL_SERVER_I_DN_SPrenamed
SSL_SERVER_ILSSL_SERVER_I_DN_Lrenamed
SSL_CLIENT_CERTIFICATESSL_CLIENT_CERTrenamed
SSL_CLIENT_CERT_STARTSSL_CLIENT_V_STARTrenamed
SSL_CLIENT_CERT_ENDSSL_CLIENT_V_ENDrenamed
SSL_CLIENT_CERT_SERIALSSL_CLIENT_M_SERIALrenamed
SSL_CLIENT_SIGNATURE_ALGORITHMSSL_CLIENT_A_SIGrenamed
SSL_CLIENT_DNSSL_CLIENT_S_DNrenamed
SSL_CLIENT_CNSSL_CLIENT_S_DN_CNrenamed
SSL_CLIENT_EMAILSSL_CLIENT_S_DN_Emailrenamed
SSL_CLIENT_OSSL_CLIENT_S_DN_Orenamed
SSL_CLIENT_OUSSL_CLIENT_S_DN_OUrenamed
SSL_CLIENT_CSSL_CLIENT_S_DN_Crenamed
SSL_CLIENT_SPSSL_CLIENT_S_DN_SPrenamed
SSL_CLIENT_LSSL_CLIENT_S_DN_Lrenamed
SSL_CLIENT_IDNSSL_CLIENT_I_DNrenamed
SSL_CLIENT_ICNSSL_CLIENT_I_DN_CNrenamed
SSL_CLIENT_IEMAILSSL_CLIENT_I_DN_Emailrenamed
SSL_CLIENT_IOSSL_CLIENT_I_DN_Orenamed
SSL_CLIENT_IOUSSL_CLIENT_I_DN_OUrenamed
SSL_CLIENT_ICSSL_CLIENT_I_DN_Crenamed
SSL_CLIENT_ISPSSL_CLIENT_I_DN_SPrenamed
SSL_CLIENT_ILSSL_CLIENT_I_DN_Lrenamed
SSL_EXPORTSSL_CIPHER_EXPORTrenamed
SSL_KEYSIZESSL_CIPHER_ALGKEYSIZErenamed
SSL_SECKEYSIZESSL_CIPHER_USEKEYSIZErenamed
SSL_SSLEAY_VERSIONSSL_VERSION_LIBRARYrenamed
SSL_STRONG_CRYPTO-Not supported by mod_ssl
SSL_SERVER_KEY_EXP-Not supported by mod_ssl
SSL_SERVER_KEY_ALGORITHM-Not supported by mod_ssl
SSL_SERVER_KEY_SIZE-Not supported by mod_ssl
SSL_SERVER_SESSIONDIR-Not supported by mod_ssl
SSL_SERVER_CERTIFICATELOGDIR-Not supported by mod_ssl
SSL_SERVER_CERTFILE-Not supported by mod_ssl
SSL_SERVER_KEYFILE-Not supported by mod_ssl
SSL_SERVER_KEYFILETYPE-Not supported by mod_ssl
SSL_CLIENT_KEY_EXP-Not supported by mod_ssl
SSL_CLIENT_KEY_ALGORITHM-Not supported by mod_ssl
SSL_CLIENT_KEY_SIZE-Not supported by mod_ssl
+ +
top
+
+

Custom Log Functions

+

+When mod_ssl is enabled, additional functions exist for the Custom Log Format of +mod_log_config as documented in the Reference +Chapter. Beside the ``%{varname}x'' +eXtension format function which can be used to expand any variables provided +by any module, an additional Cryptography +``%{name}c'' cryptography format function +exists for backward compatibility. The currently implemented function calls +are listed in Table 3.

+ +

Table 3: Custom Log Cryptography Function

+ + + + + + + + + + + + +
Function CallDescription
%...{version}c SSL protocol version
%...{cipher}c SSL cipher
%...{subjectdn}c Client Certificate Subject Distinguished Name
%...{issuerdn}c Client Certificate Issuer Distinguished Name
%...{errcode}c Certificate Verification Error (numerical)
%...{errstr}c Certificate Verification Error (string)
+ +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/ssl/ssl_compat.html.fr.utf8 b/docs/manual/ssl/ssl_compat.html.fr.utf8 new file mode 100644 index 0000000..ec1249c --- /dev/null +++ b/docs/manual/ssl/ssl_compat.html.fr.utf8 @@ -0,0 +1,257 @@ + + + + + +Chiffrement fort SSL/TLS : Compatibilité - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Chiffrement fort SSL/TLS : Compatibilité

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document couvre la compatibilité ascendante entre mod_ssl et +d'autres solutions SSL. mod_ssl n'est pas la seule solution SSL pour Apache ; +quatre autres produits sont (ou ont été) également disponibles : +Apache-SSL, le produit libre de +Ben Laurie (d'où mod_ssl est issu à l'origine en 1998), Secure +Web Server, un produit commercial de Red Hat (basé sur mod_ssl), +Raven SSL Module, un produit commercial +de Covalent (basé lui aussi sur mod_ssl), et enfin Stronghold, produit +commercial de C2Net et maintenant de Red Hat, (basé sur une branche +d'évolution différente appelée Sioux jusqu'à Stronghold 2.x et basé sur +mod_ssl depuis Stronghold 3.x).

+ +

En plus de ses fonctionnalités propres, mod_ssl rassemble la plupart de +celles des autres solutions SSL, si bien qu'il est très simple de +migrer depuis un module plus ancien vers mod_ssl. Les directives de +configuration et les noms des variables d'environnement utilisés par les +solutions SSL plus anciennes diffèrent de ceux qu'utilise mod_ssl ; +les tableaux de correspondance ci-dessous fournissent les équivalences +de termes utilisés par mod_ssl.

+
+ +
top
+
+

Directives de configuration

+

La correspondance entre les directives de configuration qu'utilise +Apache-SSL 1.x et mod_ssl 2.0.x est fournie dans le Tableau +1. La correspondance depuis Sioux 1.x et Stronghold 2.x n'est que +partielle car certaines fonctionnalités de ces interfaces ne sont pas +supportées par mod_ssl.

+ + +

Tableau 1: Correspondance entre les directives de configuration

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ancienne directiveDirective mod_sslCommentaires
Compatibilité entre Apache-SSL 1.x et mod_ssl 2.0.x :
SSLEnableSSLEngine onplus compacte
SSLDisableSSLEngine offplus compacte
SSLLogFile +fileUtilisez plutôt la directive +de niveau module LogLevel.
SSLRequiredCiphers specSSLCipherSuite specrenommée
SSLRequireCipher c1 ...SSLRequire %{SSL_CIPHER} in {"c1", +...}plus générale
SSLBanCipher c1 ...SSLRequire not (%{SSL_CIPHER} in {"c1", +...})plus générale
SSLFakeBasicAuthSSLOptions +FakeBasicAuthrassemblées
SSLCacheServerPath dir-fonctionnalité supprimée
SSLCacheServerPort integer-fonctionnalité supprimée
Compatibilité avec Apache-SSL 1.x :
SSLExportClientCertificatesSSLOptions +ExportCertDatarassemblées
SSLCacheServerRunDir dir-fonctionnalité non supportée
Compatibilité avec Sioux 1.x :
SSL_CertFile fileSSLCertificateFile filerenommée
SSL_KeyFile fileSSLCertificateKeyFile filerenommée
SSL_CipherSuite argSSLCipherSuite argrenommée
SSL_X509VerifyDir argSSLCACertificatePath argrenommée
SSL_Log +file-Utilisez plutôt la directive +de niveau module LogLevel
SSL_Connect flagSSLEngine flagrenommée
SSL_ClientAuth argSSLVerifyClient argrenommée
SSL_X509VerifyDepth argSSLVerifyDepth argrenommée
SSL_FetchKeyPhraseFrom arg-pas de véritable équivalent ; utiliser SSLPassPhraseDialog
SSL_SessionDir dir-pas de véritable équivalent ; utiliser SSLSessionCache
SSL_Require expr-pas de véritable équivalent ; utiliser SSLRequire
SSL_CertFileType arg-fonctionnalité non supportée
SSL_KeyFileType arg-fonctionnalité non supportée
SSL_X509VerifyPolicy arg-fonctionnalité non supportée
SSL_LogX509Attributes arg-fonctionnalité non supportée
Compatibilité avec Stronghold 2.x :
StrongholdAccelerator engineSSLCryptoDevice enginerenommée
StrongholdKey dir-sans objet
StrongholdLicenseFile dir-sans objet
SSLFlag flagSSLEngine flagrenommée
SSLSessionLockFile fileSSLMutex filerenommée
SSLCipherList specSSLCipherSuite specrenommée
RequireSSLSSLRequireSSLrenommée
SSLErrorFile file-fonctionnalité non supportée
SSLRoot dir-fonctionnalité non supportée
SSL_CertificateLogDir dir-fonctionnalité non supportée
AuthCertDir dir-fonctionnalité non supportée
SSL_Group name-fonctionnalité non supportée
SSLProxyMachineCertPath dirSSLProxyMachineCertificatePath dirrenommée
SSLProxyMachineCertFile fileSSLProxyMachineCertificateFile filerenommée
SSLProxyCipherList specSSLProxyCipherSpec specrenommée
+ +
top
+
+

Variables d'environnement

+ +

La correspondance entre les noms des variables d'environnement utilisés par +les solutions SSL plus anciennes et les noms utilisés par mod_ssl est fournie +dans le Tableau 2.

+ +

Tableau 2: Dérivation des variables d'environnement

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Ancienne variableVariable mod_sslCommentaires
SSL_PROTOCOL_VERSIONSSL_PROTOCOLrenommée
SSLEAY_VERSIONSSL_VERSION_LIBRARYrenommée
HTTPS_SECRETKEYSIZESSL_CIPHER_USEKEYSIZErenommée
HTTPS_KEYSIZESSL_CIPHER_ALGKEYSIZErenommée
HTTPS_CIPHERSSL_CIPHERrenommée
HTTPS_EXPORTSSL_CIPHER_EXPORTrenommée
SSL_SERVER_KEY_SIZESSL_CIPHER_ALGKEYSIZErenommée
SSL_SERVER_CERTIFICATESSL_SERVER_CERTrenommée
SSL_SERVER_CERT_STARTSSL_SERVER_V_STARTrenommée
SSL_SERVER_CERT_ENDSSL_SERVER_V_ENDrenommée
SSL_SERVER_CERT_SERIALSSL_SERVER_M_SERIALrenommée
SSL_SERVER_SIGNATURE_ALGORITHMSSL_SERVER_A_SIGrenommée
SSL_SERVER_DNSSL_SERVER_S_DNrenommée
SSL_SERVER_CNSSL_SERVER_S_DN_CNrenommée
SSL_SERVER_EMAILSSL_SERVER_S_DN_Emailrenommée
SSL_SERVER_OSSL_SERVER_S_DN_Orenommée
SSL_SERVER_OUSSL_SERVER_S_DN_OUrenommée
SSL_SERVER_CSSL_SERVER_S_DN_Crenommée
SSL_SERVER_SPSSL_SERVER_S_DN_SPrenommée
SSL_SERVER_LSSL_SERVER_S_DN_Lrenommée
SSL_SERVER_IDNSSL_SERVER_I_DNrenommée
SSL_SERVER_ICNSSL_SERVER_I_DN_CNrenommée
SSL_SERVER_IEMAILSSL_SERVER_I_DN_Emailrenommée
SSL_SERVER_IOSSL_SERVER_I_DN_Orenommée
SSL_SERVER_IOUSSL_SERVER_I_DN_OUrenommée
SSL_SERVER_ICSSL_SERVER_I_DN_Crenommée
SSL_SERVER_ISPSSL_SERVER_I_DN_SPrenommée
SSL_SERVER_ILSSL_SERVER_I_DN_Lrenommée
SSL_CLIENT_CERTIFICATESSL_CLIENT_CERTrenommée
SSL_CLIENT_CERT_STARTSSL_CLIENT_V_STARTrenommée
SSL_CLIENT_CERT_ENDSSL_CLIENT_V_ENDrenommée
SSL_CLIENT_CERT_SERIALSSL_CLIENT_M_SERIALrenommée
SSL_CLIENT_SIGNATURE_ALGORITHMSSL_CLIENT_A_SIGrenommée
SSL_CLIENT_DNSSL_CLIENT_S_DNrenommée
SSL_CLIENT_CNSSL_CLIENT_S_DN_CNrenommée
SSL_CLIENT_EMAILSSL_CLIENT_S_DN_Emailrenommée
SSL_CLIENT_OSSL_CLIENT_S_DN_Orenommée
SSL_CLIENT_OUSSL_CLIENT_S_DN_OUrenommée
SSL_CLIENT_CSSL_CLIENT_S_DN_Crenommée
SSL_CLIENT_SPSSL_CLIENT_S_DN_SPrenommée
SSL_CLIENT_LSSL_CLIENT_S_DN_Lrenommée
SSL_CLIENT_IDNSSL_CLIENT_I_DNrenommée
SSL_CLIENT_ICNSSL_CLIENT_I_DN_CNrenommée
SSL_CLIENT_IEMAILSSL_CLIENT_I_DN_Emailrenommée
SSL_CLIENT_IOSSL_CLIENT_I_DN_Orenommée
SSL_CLIENT_IOUSSL_CLIENT_I_DN_OUrenommée
SSL_CLIENT_ICSSL_CLIENT_I_DN_Crenommée
SSL_CLIENT_ISPSSL_CLIENT_I_DN_SPrenommée
SSL_CLIENT_ILSSL_CLIENT_I_DN_Lrenommée
SSL_EXPORTSSL_CIPHER_EXPORTrenommée
SSL_KEYSIZESSL_CIPHER_ALGKEYSIZErenommée
SSL_SECKEYSIZESSL_CIPHER_USEKEYSIZErenommée
SSL_SSLEAY_VERSIONSSL_VERSION_LIBRARYrenommée
SSL_STRONG_CRYPTO-Non supportée par mod_ssl
SSL_SERVER_KEY_EXP-Non supportée par mod_ssl
SSL_SERVER_KEY_ALGORITHM-Non supportée par mod_ssl
SSL_SERVER_KEY_SIZE-Non supportée par mod_ssl
SSL_SERVER_SESSIONDIR-Non supportée par mod_ssl
SSL_SERVER_CERTIFICATELOGDIR-Non supportée par mod_ssl
SSL_SERVER_CERTFILE-Non supportée par mod_ssl
SSL_SERVER_KEYFILE-Non supportée par mod_ssl
SSL_SERVER_KEYFILETYPE-Non supportée par mod_ssl
SSL_CLIENT_KEY_EXP-Non supportée par mod_ssl
SSL_CLIENT_KEY_ALGORITHM-Non supportée par mod_ssl
SSL_CLIENT_KEY_SIZE-Non supportée par mod_ssl
+ +
top
+
+

Fonctions de personnalisation des journaux

+

Quand mod_ssl est activé, le Format de journal courant +(Custom Log Format) du module mod_log_config possède +des fonctions supplémentaires comme indiqué dans le chapitre de référence. +En plus de la fonction de format étendu +``%{varname}x'' que l'on peut utiliser pour +extraire le contenu d'une variable fournie par n'importe quel module, +la fonction +de format cryptographique ``%{name}c'' a +été ajoutée à des fins de compatibilité ascendante. Les appels de fonctions +actuellement implémentés sont énumérés dans le +Tableau 3.

+ +

Table 3: Fonctions cryptographiques du format de journal courant

+ + + + + + + + + + + + +
Appel de fonctionDescription
%...{version}c Version du protocole SSL
%...{cipher}c Chiffrement SSL
%...{subjectdn}c Nom distinctif du sujet du certificat du client
%...{issuerdn}c Nom distinctif de l'émetteur du certificat du client
%...{errcode}c Erreur lors de la vérification du certificat (numérique)
%...{errstr}c Erreur lors de la vérification du certificat (chaîne de caractères)
+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/ssl/ssl_faq.html b/docs/manual/ssl/ssl_faq.html new file mode 100644 index 0000000..db96c12 --- /dev/null +++ b/docs/manual/ssl/ssl_faq.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: ssl_faq.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: ssl_faq.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/ssl/ssl_faq.html.en b/docs/manual/ssl/ssl_faq.html.en new file mode 100644 index 0000000..a95b4e1 --- /dev/null +++ b/docs/manual/ssl/ssl_faq.html.en @@ -0,0 +1,935 @@ + + + + + +SSL/TLS Strong Encryption: FAQ - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

SSL/TLS Strong Encryption: FAQ

+
+

Available Languages:  en  | + fr 

+
+ +
+

The wise man doesn't give the right answers, +he poses the right questions.

+

-- Claude Levi-Strauss

+ +
+
+ +
top
+
+

Installation

+ + +

Why do I get permission errors related to + SSLMutex when I start Apache?

+

Errors such as ``mod_ssl: Child could not open + SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows) + [...] System: Permission denied (errno: 13)'' are usually + caused by overly restrictive permissions on the parent directories. + Make sure that all parent directories (here /opt, + /opt/apache and /opt/apache/logs) have the x-bit + set for, at minimum, the UID under which Apache's children are running (see + the User directive).

+ + +

Why does mod_ssl stop with the error + "Failed to generate temporary 512 bit RSA private key" when I start + Apache?

+

Cryptographic software needs a source of unpredictable data + to work correctly. Many open source operating systems provide + a "randomness device" that serves this purpose (usually named + /dev/random). On other systems, applications have to + seed the OpenSSL Pseudo Random Number Generator (PRNG) manually with + appropriate data before generating keys or performing public key + encryption. As of version 0.9.5, the OpenSSL functions that need + randomness report an error if the PRNG has not been seeded with + at least 128 bits of randomness.

+

To prevent this error, mod_ssl has to provide + enough entropy to the PRNG to allow it to work correctly. This can + be done via the SSLRandomSeed + directive.

+ +
top
+
+

Configuration

+ + +

Is it possible to provide HTTP and HTTPS + from the same server?

+

Yes. HTTP and HTTPS use different server ports (HTTP binds to + port 80, HTTPS to port 443), so there is no direct conflict between + them. You can either run two separate server instances bound to + these ports, or use Apache's elegant virtual hosting facility to + create two virtual servers, both served by the same instance of Apache + - one responding over HTTP to requests on port 80, and the other + responding over HTTPS to requests on port 443.

+ + +

Which port does HTTPS use?

+

You can run HTTPS on any port, but the standards specify port 443, which + is where any HTTPS compliant browser will look by default. You can force + your browser to look on a different port by specifying it in the URL. For + example, if your server is set up to serve pages over HTTPS on port 8080, + you can access them at https://example.com:8080/

+ + +

How do I speak HTTPS manually for testing purposes?

+

While you usually just use

+ +

$ telnet localhost 80
+ GET / HTTP/1.0

+ +

for simple testing of Apache via HTTP, it's not so easy for + HTTPS because of the SSL protocol between TCP and HTTP. With the + help of OpenSSL's s_client command, however, you can + do a similar check via HTTPS:

+ +

$ openssl s_client -connect localhost:443 -state -debug
+ GET / HTTP/1.0

+ +

Before the actual HTTP response you will receive detailed + information about the SSL handshake. For a more general command + line client which directly understands both HTTP and HTTPS, can + perform GET and POST operations, can use a proxy, supports byte + ranges, etc. you should have a look at the nifty + cURL tool. Using this, you can + check that Apache is responding correctly to requests via HTTP and + HTTPS as follows:

+ +

$ curl http://localhost/
+ $ curl https://localhost/

+ + +

Why does the connection hang when I connect + to my SSL-aware Apache server?

+ +

This can happen when you try to connect to a HTTPS server (or virtual + server) via HTTP (eg, using http://example.com/ instead of + https://example.com). It can also happen when trying to + connect via HTTPS to a HTTP server (eg, using + https://example.com/ on a server which doesn't support HTTPS, + or which supports it on a non-standard port). Make sure that you're + connecting to a (virtual) server that supports SSL.

+ +

Why do I get ``Connection Refused'' messages, + when trying to access my newly installed Apache+mod_ssl server via HTTPS?

+

+ This error can be caused by an incorrect configuration. + Please make sure that your Listen directives match your + <VirtualHost> + directives. If all else fails, please start afresh, using the default + configuration provided by mod_ssl.

+ + +

Why are the SSL_XXX variables + not available to my CGI & SSI scripts?

+

Please make sure you have ``SSLOptions +StdEnvVars'' + enabled for the context of your CGI/SSI requests.

+ + +

How can I switch between HTTP and HTTPS in relative + hyperlinks?

+ +

Usually, to switch between HTTP and HTTPS, you have to use + fully-qualified hyperlinks (because you have to change the URL + scheme). Using mod_rewrite however, you can + manipulate relative hyperlinks, to achieve the same effect.

+ 
RewriteEngine on
+RewriteRule   "^/(.*)_SSL$"   "https://%{SERVER_NAME}/$1" [R,L]
+RewriteRule   "^/(.*)_NOSSL$" "http://%{SERVER_NAME}/$1"  [R,L]
+ + +

This rewrite ruleset lets you use hyperlinks of the form + <a href="document.html_SSL">, to switch to HTTPS + in a relative link. (Replace SSL with NOSSL to switch to HTTP.)

+ +
top
+
+

Certificates

+ + +

What are RSA Private Keys, CSRs and Certificates?

+

An RSA private key file is a digital file that you can use to decrypt + messages sent to you. It has a public component which you distribute (via + your Certificate file) which allows people to encrypt those messages to + you.

+

A Certificate Signing Request (CSR) is a digital file which contains + your public key and your name. You send the CSR to a Certifying Authority + (CA), who will convert it into a real Certificate, by signing it.

+

A Certificate contains your + RSA public key, your name, the name of the CA, and is digitally signed by + the CA. Browsers that know the CA can verify the signature on that + Certificate, thereby obtaining your RSA public key. That enables them to + send messages which only you can decrypt.

+

See the Introduction chapter for a general + description of the SSL protocol.

+ + +

Is there a difference on startup between + a non-SSL-aware Apache and an SSL-aware Apache?

+

Yes. In general, starting Apache with + mod_ssl built-in is just like starting Apache + without it. However, if you have a passphrase on your SSL private + key file, a startup dialog will pop up which asks you to enter the + pass phrase.

+ +

Having to manually enter the passphrase when starting the server + can be problematic - for example, when starting the server from the + system boot scripts. In this case, you can follow the steps + below to remove the passphrase from + your private key. Bear in mind that doing so brings additional security + risks - proceed with caution!

+ + +

How do I create a self-signed SSL +Certificate for testing purposes?

+
    +
  1. Make sure OpenSSL is installed and in your PATH.
    +
    +
    2. +
  2. Run the following command, to create server.key and + server.crt files:
    + $ openssl req -new -x509 -nodes -out server.crt + -keyout server.key
    + These can be used as follows in your httpd.conf + file: + 
    SSLCertificateFile    "/path/to/this/server.crt"
+SSLCertificateKeyFile "/path/to/this/server.key"
    + +
    3. +
  3. It is important that you are aware that this + server.key does not have any passphrase. + To add a passphrase to the key, you should run the following + command, and enter & verify the passphrase as requested.
    +

    $ openssl rsa -des3 -in server.key -out + server.key.new
    + $ mv server.key.new server.key

    + Please backup the server.key file, and the passphrase + you entered, in a secure location. +
    4. +
+ + +

How do I create a real SSL Certificate?

+

Here is a step-by-step description:

+
    +
  1. Make sure OpenSSL is installed and in your PATH. +
    +
    +
    2. +
  2. Create a RSA private key for your Apache server + (will be Triple-DES encrypted and PEM formatted):
    +
    + $ openssl genrsa -des3 -out server.key 2048
    +
    + Please backup this server.key file and the + pass-phrase you entered in a secure location. + You can see the details of this RSA private key by using the command:
    + +
    + $ openssl rsa -noout -text -in server.key
    +
    + If necessary, you can also create a decrypted PEM version (not + recommended) of this RSA private key with:
    +
    + $ openssl rsa -in server.key -out server.key.unsecure
    +
    + +
    3. +
  3. Create a Certificate Signing Request (CSR) with the server RSA private + key (output will be PEM formatted):
    +
    + $ openssl req -new -key server.key -out server.csr
    +
    + Make sure you enter the FQDN ("Fully Qualified Domain Name") of the + server when OpenSSL prompts you for the "CommonName", i.e. when you + generate a CSR for a website which will be later accessed via + https://www.foo.dom/, enter "www.foo.dom" here. + You can see the details of this CSR by using
    + +
    + $ openssl req -noout -text -in server.csr
    +
    +
    4. +
  4. You now have to send this Certificate Signing Request (CSR) to + a Certifying Authority (CA) to be signed. Once the CSR has been + signed, you will have a real Certificate, which can be used by + Apache. You can have a CSR signed by a commercial CA, or you can + create your own CA to sign it.
    + Commercial CAs usually ask you to post the CSR into a web form, + pay for the signing, and then send a signed Certificate, which + you can store in a server.crt file.
    + + For details on how to create your own CA, and use this to sign + a CSR, see below.
    + + Once your CSR has been signed, you can see the details of the + Certificate as follows:
    +
    + $ openssl x509 -noout -text -in server.crt
    + +
    5. +
  5. You should now have two files: server.key and + server.crt. These can be used as follows in your + httpd.conf file: + 
    SSLCertificateFile    "/path/to/this/server.crt"
+SSLCertificateKeyFile "/path/to/this/server.key"
    + + The server.csr file is no longer needed. +
    6. + +
+ + +

How do I create and use my own Certificate Authority (CA)?

+

The short answer is to use the CA.sh or CA.pl + script provided by OpenSSL. Unless you have a good reason not to, + you should use these for preference. If you cannot, you can create a + self-signed certificate as follows:

+ +
    +
  1. Create a RSA private key for your server + (will be Triple-DES encrypted and PEM formatted):
    +
    + $ openssl genrsa -des3 -out server.key 2048
    +
    + Please backup this server.key file and the + pass-phrase you entered in a secure location. + You can see the details of this RSA private key by using the + command:
    +
    + $ openssl rsa -noout -text -in server.key
    +
    + If necessary, you can also create a decrypted PEM version (not + recommended) of this RSA private key with:
    +
    + $ openssl rsa -in server.key -out server.key.unsecure
    +
    +
    2. +
  2. Create a self-signed certificate (X509 structure) + with the RSA key you just created (output will be PEM formatted):
    +
    + $ openssl req -new -x509 -nodes -sha1 -days 365 + -key server.key -out server.crt -extensions usr_cert
    +
    + This signs the server CSR and results in a server.crt file.
    + You can see the details of this Certificate using:
    +
    + $ openssl x509 -noout -text -in server.crt
    +
    +
    3. +
+ + +

How can I change the pass-phrase on my private key file?

+

You simply have to read it with the old pass-phrase and write it again, + specifying the new pass-phrase. You can accomplish this with the following + commands:

+ + +

$ openssl rsa -des3 -in server.key -out server.key.new
+ $ mv server.key.new server.key

+ +

The first time you're asked for a PEM pass-phrase, you should + enter the old pass-phrase. After that, you'll be asked again to + enter a pass-phrase - this time, use the new pass-phrase. If you + are asked to verify the pass-phrase, you'll need to enter the new + pass-phrase a second time.

+ + +

How can I get rid of the pass-phrase dialog at Apache startup time?

+

The reason this dialog pops up at startup and every re-start + is that the RSA private key inside your server.key file is stored in + encrypted format for security reasons. The pass-phrase is needed to decrypt + this file, so it can be read and parsed. Removing the pass-phrase + removes a layer of security from your server - proceed with caution!

+
    +
  1. Remove the encryption from the RSA private key (while + keeping a backup copy of the original file):
    +
    + $ cp server.key server.key.org
    + $ openssl rsa -in server.key.org -out server.key
    + +
    +
    2. +
  2. Make sure the server.key file is only readable by root:
    +
    + $ chmod 400 server.key
    +
    +
    3. +
+ +

Now server.key contains an unencrypted copy of the key. + If you point your server at this file, it will not prompt you for a + pass-phrase. HOWEVER, if anyone gets this key they will be able to + impersonate you on the net. PLEASE make sure that the permissions on this + file are such that only root or the web server user can read it + (preferably get your web server to start as root but run as another + user, and have the key readable only by root).

+ +

As an alternative approach you can use the ``SSLPassPhraseDialog + exec:/path/to/program'' facility. Bear in mind that this is + neither more nor less secure, of course.

+ + +

How do I verify that a private key matches its Certificate?

+

A private key contains a series of numbers. Two of these numbers form + the "public key", the others are part of the "private key". The "public + key" bits are included when you generate a CSR, and subsequently form + part of the associated Certificate.

+

To check that the public key in your Certificate matches the public + portion of your private key, you simply need to compare these numbers. + To view the Certificate and the key run the commands:

+ +

$ openssl x509 -noout -text -in server.crt
+ $ openssl rsa -noout -text -in server.key

+ +

The `modulus' and the `public exponent' portions in the key and the + Certificate must match. As the public exponent is usually 65537 + and it's difficult to visually check that the long modulus numbers + are the same, you can use the following approach:

+ +

$ openssl x509 -noout -modulus -in server.crt | openssl md5
+ $ openssl rsa -noout -modulus -in server.key | openssl md5

+ +

This leaves you with two rather shorter numbers to compare. It is, + in theory, possible that these numbers may be the same, without the + modulus numbers being the same, but the chances of this are + overwhelmingly remote.

+

Should you wish to check to which key or certificate a particular + CSR belongs you can perform the same calculation on the CSR as + follows:

+ +

$ openssl req -noout -modulus -in server.csr | openssl md5

+ + +

How can I convert a certificate from PEM to DER format?

+

The default certificate format for OpenSSL is PEM, which is simply + Base64 encoded DER, with header and footer lines. For some applications + (e.g. Microsoft Internet Explorer) you need the certificate in plain DER + format. You can convert a PEM file cert.pem into the + corresponding DER file cert.der using the following command: + $ openssl x509 -in cert.pem -out cert.der -outform DER

+ + +

Why do browsers complain that they cannot verify my server certificate?

+ +

One reason this might happen is because your server certificate is signed + by an intermediate CA. Various CAs, such as Verisign or Thawte, have started + signing certificates not with their root certificate but with intermediate + certificates.

+ +

Intermediate CA certificates lie between the root CA certificate (which is + installed in the browsers) and the server certificate (which you installed + on the server). In order for the browser to be able to traverse and verify + the trust chain from the server certificate to the root certificate it + needs need to be given the intermediate certificates. The CAs should + be able to provide you such intermediate certificate packages that can be + installed on the server.

+ +

You need to include those intermediate certificates with the + SSLCertificateChainFile + directive.

+ +
top
+
+

The SSL Protocol

+ + +

Why do I get lots of random SSL protocol +errors under heavy server load?

+

There can be a number of reasons for this, but the main one + is problems with the SSL session Cache specified by the + SSLSessionCache directive. The DBM session + cache is the most likely source of the problem, so using the SHM session cache (or + no cache at all) may help.

+ + +

Why does my webserver have a higher load, now +that it serves SSL encrypted traffic?

+

SSL uses strong cryptographic encryption, which necessitates a lot of + number crunching. When you request a webpage via HTTPS, everything (even + the images) is encrypted before it is transferred. So increased HTTPS + traffic leads to load increases.

+ + +

Why do HTTPS connections to my server +sometimes take up to 30 seconds to establish a connection?

+

This is usually caused by a /dev/random device for + SSLRandomSeed which blocks the + read(2) call until enough entropy is available to service the + request. More information is available in the reference + manual for the SSLRandomSeed + directive.

+ + +

What SSL Ciphers are supported by mod_ssl?

+

Usually, any SSL ciphers supported by the version of OpenSSL in use, + are also supported by mod_ssl. Which ciphers are + available can depend on the way you built OpenSSL. Typically, at + least the following ciphers are supported:

+ +
    +
  1. RC4 with SHA1
    2. +
  2. AES with SHA1
    3. +
  3. Triple-DES with SHA1
    4. +
+ +

To determine the actual list of ciphers available, you should run + the following:

+

$ openssl ciphers -v

+ + +

Why do I get ``no shared cipher'' errors, when +trying to use Anonymous Diffie-Hellman (ADH) ciphers?

+

By default, OpenSSL does not allow ADH ciphers, for security + reasons. Please be sure you are aware of the potential side-effects + if you choose to enable these ciphers.

+

In order to use Anonymous Diffie-Hellman (ADH) ciphers, you must + build OpenSSL with ``-DSSL_ALLOW_ADH'', and then add + ``ADH'' into your SSLCipherSuite.

+ + +

Why do I get a 'no shared ciphers' +error when connecting to my newly installed server?

+

Either you have made a mistake with your + SSLCipherSuite + directive (compare it with the pre-configured example in + extra/httpd-ssl.conf) or you chose to use DSA/DH + algorithms instead of RSA when you generated your private key + and ignored or overlooked the warnings. If you have chosen + DSA/DH, then your server cannot communicate using RSA-based SSL + ciphers (at least until you configure an additional RSA-based + certificate/key pair). Modern browsers like NS or IE can only + communicate over SSL using RSA ciphers. The result is the + "no shared ciphers" error. To fix this, regenerate your server + certificate/key pair, using the RSA algorithm.

+ + +

Why can't I use SSL with name-based/non-IP-based virtual hosts?

+

The reason is very technical, and a somewhat "chicken and egg" problem. + The SSL protocol layer stays below the HTTP protocol layer and + encapsulates HTTP. When an SSL connection (HTTPS) is established + Apache/mod_ssl has to negotiate the SSL protocol parameters with the + client. For this, mod_ssl has to consult the configuration of the virtual + server (for instance it has to look for the cipher suite, the server + certificate, etc.). But in order to go to the correct virtual server + Apache has to know the Host HTTP header field. To do this, the + HTTP request header has to be read. This cannot be done before the SSL + handshake is finished, but the information is needed in order to + complete the SSL handshake phase. See the next question for how to + circumvent this issue.

+ +

Note that if you have a wildcard SSL certificate, or a + certificate that has multiple hostnames on it using subjectAltName + fields, you can use SSL on name-based virtual hosts without further + workarounds.

+ + +

Is it possible to use Name-Based +Virtual Hosting to identify different SSL virtual hosts?

+

Name-Based Virtual Hosting is a very popular method of identifying + different virtual hosts. It allows you to use the same IP address and + the same port number for many different sites. When people move on to + SSL, it seems natural to assume that the same method can be used to have + lots of different SSL virtual hosts on the same server.

+ +

It is possible, but only if using a 2.2.12 or later web server, + built with 0.9.8j or later OpenSSL. This is because it requires a + feature that only the most recent revisions of the SSL + specification added, called Server Name Indication (SNI).

+ +

Note that if you have a wildcard SSL certificate, or a + certificate that has multiple hostnames on it using subjectAltName + fields, you can use SSL on name-based virtual hosts without further + workarounds.

+ +

The reason is that the SSL protocol is a separate layer which + encapsulates the HTTP protocol. So the SSL session is a separate + transaction, that takes place before the HTTP session has begun. + The server receives an SSL request on IP address X and port Y + (usually 443). Since the SSL request did not contain any Host: + field, the server had no way to decide which SSL virtual host to use. + Usually, it just used the first one it found which matched the + port and IP address specified.

+ +

If you are using a version of the web server and OpenSSL that + support SNI, though, and the client's browser also supports SNI, + then the hostname is included in the original SSL request, and the + web server can select the correct SSL virtual host.

+ +

You can, of course, use Name-Based Virtual Hosting to identify many + non-SSL virtual hosts (all on port 80, for example) and then + have a single SSL virtual host (on port 443). But if you do this, + you must make sure to put the non-SSL port number on the NameVirtualHost + directive, e.g.

+ + 
NameVirtualHost 192.168.1.1:80
+ + +

Other workaround solutions include:

+ +

Using separate IP addresses for different SSL hosts. + Using different port numbers for different SSL hosts.

+ + +

How do I get SSL compression working?

+

Although SSL compression negotiation was defined in the specification +of SSLv2 and TLS, it took until May 2004 for RFC 3749 to define DEFLATE as +a negotiable standard compression method. +

+

OpenSSL 0.9.8 started to support this by default when compiled with the +zlib option. If both the client and the server support compression, +it will be used. However, most clients still try to initially connect with an +SSLv2 Hello. As SSLv2 did not include an array of preferred compression algorithms +in its handshake, compression cannot be negotiated with these clients. +If the client disables support for SSLv2, either an SSLv3 or TLS Hello +may be sent, depending on which SSL library is used, and compression may +be set up. You can verify whether clients make use of SSL compression by +logging the %{SSL_COMPRESS_METHOD}x variable. +

+ + +

When I use Basic Authentication over HTTPS +the lock icon in Netscape browsers stays unlocked when the dialog pops up. +Does this mean the username/password is being sent unencrypted?

+

No, the username/password is transmitted encrypted. The icon in + Netscape browsers is not actually synchronized with the SSL/TLS layer. + It only toggles to the locked state when the first part of the actual + webpage data is transferred, which may confuse people. The Basic + Authentication facility is part of the HTTP layer, which is above + the SSL/TLS layer in HTTPS. Before any HTTP data communication takes + place in HTTPS, the SSL/TLS layer has already completed its handshake + phase, and switched to encrypted communication. So don't be + confused by this icon.

+ + +

Why do I get I/O errors when connecting via +HTTPS to an Apache+mod_ssl server with older versions of Microsoft Internet +Explorer (MSIE)?

+

The first reason is that the SSL implementation in some MSIE versions has + some subtle bugs related to the HTTP keep-alive facility and the SSL close + notify alerts on socket connection close. Additionally the interaction + between SSL and HTTP/1.1 features are problematic in some MSIE versions. + You can work around these problems by forcing Apache not to use HTTP/1.1, + keep-alive connections or send the SSL close notify messages to MSIE clients. + This can be done by using the following directive in your SSL-aware + virtual host section:

+ 
SetEnvIf User-Agent "MSIE [2-5]" \
+         nokeepalive ssl-unclean-shutdown \
+         downgrade-1.0 force-response-1.0
+ +

Further, some MSIE versions have problems with particular ciphers. + Unfortunately, it is not possible to implement a MSIE-specific + workaround for this, because the ciphers are needed as early as the + SSL handshake phase. So a MSIE-specific + SetEnvIf won't solve these + problems. Instead, you will have to make more drastic + adjustments to the global parameters. Before you decide to do + this, make sure your clients really have problems. If not, do not + make these changes - they will affect all your clients, MSIE + or otherwise.

+ + +

How do I enable TLS-SRP?

+

TLS-SRP (Secure Remote Password key exchange for TLS, specified in RFC 5054) + can supplement or replace certificates in authenticating an SSL connection. + To use TLS-SRP, set the + SSLSRPVerifierFile directive to + point to an OpenSSL SRP verifier file. To create the verifier file, use the + openssl tool:

+

+ openssl srp -srpvfile passwd.srpv -add username +

+

After creating this file, specify it in the SSL server configuration:

+

+ SSLSRPVerifierFile /path/to/passwd.srpv +

+

To force clients to use non-certificate TLS-SRP cipher suites, use the + following directive:

+

+ SSLCipherSuite "!DSS:!aRSA:SRP" +

+ + +

Why do I get handshake failures with Java-based clients when using a certificate with more than 1024 bits?

+

Beginning with version 2.4.7, + mod_ssl will use DH parameters which include primes + with lengths of more than 1024 bits. Java 7 and earlier limit their + support for DH prime sizes to a maximum of 1024 bits, however.

+ +

If your Java-based client aborts with exceptions such as + java.lang.RuntimeException: Could not generate DH keypair and + java.security.InvalidAlgorithmParameterException: Prime size must be + multiple of 64, and can only range from 512 to 1024 (inclusive), + and httpd logs tlsv1 alert internal error (SSL alert number 80) + (at LogLevel info + or higher), you can either rearrange mod_ssl's cipher list with + SSLCipherSuite + (possibly in conjunction with SSLHonorCipherOrder), + or you can use custom DH parameters with a 1024-bit prime, which + will always have precedence over any of the built-in DH parameters.

+ +

To generate custom DH parameters, use the openssl dhparam 1024 + command. Alternatively, you can use the following standard 1024-bit DH + parameters from RFC 2409, + section 6.2:

+ 
-----BEGIN DH PARAMETERS-----
+MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
+Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
+/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
+-----END DH PARAMETERS-----
+

Add the custom parameters including the "BEGIN DH PARAMETERS" and + "END DH PARAMETERS" lines to the end of the first certificate file + you have configured using the + SSLCertificateFile directive.

+ + +
top
+
+

mod_ssl Support

+ + +

What information resources are available in case of mod_ssl problems?

+

The following information resources are available. + In case of problems you should search here first.

+ +
+
Answers in the User Manual's F.A.Q. List (this)
+
+ http://httpd.apache.org/docs/2.4/ssl/ssl_faq.html
+ First check the F.A.Q. (this text). If your problem is a common + one, it may have been answered several times before, and been included + in this doc. +
+
+ + +

What support contacts are available in case +of mod_ssl problems?

+

The following lists all support possibilities for mod_ssl, in order of + preference. Please go through these possibilities + in this order - don't just pick the one you like the look of.

+
    + +
  1. Send a Problem Report to the Apache httpd Users Support Mailing List
    + + users@httpd.apache.org
    + This is the second way of submitting your problem report. Again, you must + subscribe to the list first, but you can then easily discuss your problem + with the whole Apache httpd user community. +
    2. + +
  2. Write a Problem Report in the Bug Database
    + + http://httpd.apache.org/bug_report.html
    + This is the last way of submitting your problem report. You should only + do this if you've already posted to the mailing lists, and had no success. + Please follow the instructions on the above page carefully. +
    3. +
+ + +

What information should I +provide when writing a bug report?

+

You should always provide at least the following information:

+ +
+
Apache httpd and OpenSSL version information
+
The Apache version can be determined + by running httpd -v. The OpenSSL version can be + determined by running openssl version. Alternatively, if + you have Lynx installed, you can run the command lynx -mime_header + http://localhost/ | grep Server to gather this information in a + single step. +
+ +
The details on how you built and installed Apache httpd and OpenSSL
+
For this you can provide a logfile of your terminal session which shows + the configuration and install steps. If this is not possible, you + should at least provide the configure command line you used. +
+ +
In case of core dumps please include a Backtrace
+
If your Apache httpd dumps its core, please attach + a stack-frame ``backtrace'' (see below + for information on how to get this). This information is required + in order to find a reason for your core dump. +
+ +
A detailed description of your problem
+
Don't laugh, we really mean it! Many problem reports don't + include a description of what the actual problem is. Without this, + it's very difficult for anyone to help you. So, it's in your own + interest (you want the problem be solved, don't you?) to include as + much detail as possible, please. Of course, you should still include + all the essentials above too. +
+
+ + +

I had a core dump, can you help me?

+

In general no, at least not unless you provide more details about the code + location where Apache dumped core. What is usually always required in + order to help you is a backtrace (see next question). Without this + information it is mostly impossible to find the problem and help you in + fixing it.

+ + +

How do I get a backtrace, to help find +the reason for my core dump?

+

Following are the steps you will need to complete, to get a backtrace:

+
    +
  1. Make sure you have debugging symbols available, at least + in Apache. On platforms where you use GCC/GDB, you will have to build + Apache+mod_ssl with ``OPTIM="-g -ggdb3"'' to get this. On + other platforms at least ``OPTIM="-g"'' is needed. +
    2. + +
  2. Start the server and try to reproduce the core-dump. For this you may + want to use a directive like ``CoreDumpDirectory /tmp'' to + make sure that the core-dump file can be written. This should result + in a /tmp/core or /tmp/httpd.core file. If you + don't get one of these, try running your server under a non-root UID. + Many modern kernels do not allow a process to dump core after it has + done a setuid() (unless it does an exec()) for + security reasons (there can be privileged information left over in + memory). If necessary, you can run /path/to/httpd -X + manually to force Apache to not fork. +
    3. + +
  3. Analyze the core-dump. For this, run gdb /path/to/httpd + /tmp/httpd.core or a similar command. In GDB, all you + have to do then is to enter bt, and voila, you get the + backtrace. For other debuggers consult your local debugger manual. +
    4. +
+ +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/ssl/ssl_faq.html.fr.utf8 b/docs/manual/ssl/ssl_faq.html.fr.utf8 new file mode 100644 index 0000000..73159e0 --- /dev/null +++ b/docs/manual/ssl/ssl_faq.html.fr.utf8 @@ -0,0 +1,1036 @@ + + + + + +Chiffrement SSL/TLS fort: foire aux questions - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Chiffrement SSL/TLS fort: foire aux questions

+
+

Langues Disponibles:  en  | + fr 

+
+ +
+

Le sage n'apporte pas de bonnes réponses, il pose les bonnes questions

+

-- Claude Levi-Strauss

+ +
+
+ +
top
+
+

Installation

+ + +

Pourquoi le démarrage d'Apache provoque-t-il des +erreurs de permission en rapport avec SSLMutex ?

+

Des erreurs telles que ``mod_ssl: Child could not open + SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (avec l'erreur + système qui suit) [...] System: Permission denied (errno: 13)'' + sont souvent provoquées par des permissions trop restrictives sur les + répertoires parents. Assurez-vous que tous les répertoires + parents (ici /opt, /opt/apache et + /opt/apache/logs) ont le bit x positionné au moins pour + l'UID sous lequel les processus enfants d'Apache s'exécutent (voir la + directive User).

+ + +

Pourquoi mod_ssl s'arrête-t-il avec l'erreur +"Failed to generate temporary 512 bit RSA private key" au démarrage +d'Apache ?

+

Pour fonctionner correctement, les logiciels de cryptographie ont + besoin d'une source de données aléatoires. De nombreux systèmes + d'exploitation libres proposent un "périphérique source d'entropie" + qui fournit ce service (il se nomme en général + /dev/random). Sur d'autres systèmes, les applications + doivent amorcer manuellement + le Générateur de Nombres Pseudo-Aléatoires d'OpenSSL + (Pseudo Random Number Generator -PRNG) à l'aide de données appropriées + avant de générer des clés ou d'effectuer un chiffrement à clé + publique. Depuis la version 0.9.5, les fonctions d'OpenSSL qui nécessitent + des données aléatoires provoquent une erreur si le PRNG n'a pas été amorcé + avec une source de données aléatoires d'au moins 128 bits.

+

Pour éviter cette erreur, mod_ssl doit fournir + suffisamment d'entropie au PRNG pour lui permettre de fonctionner + correctement. Ce niveau d'entropie est défini par la directive + SSLRandomSeed.

+ +
top
+
+

Configuration

+ + +

Peut-on faire cohabiter HTTP et HTTPS sur le même +serveur ?

+

Oui. HTTP et HTTPS utilisent des ports différents (HTTP écoute le port + 80 et HTTPS le port 443), si bien qu'il n'y a pas de conflit direct entre + les deux. Vous pouvez soit exécuter deux instances séparées du serveur, + chacune d'entre elles écoutant l'un de ces ports, soit utiliser l'élégante + fonctionnalité d'Apache que constituent les hôtes virtuels pour créer + deux serveurs virtuels gérés par la même instance d'Apache - le + premier serveur répondant en HTTP aux requêtes sur le port 80, + le second répondant en HTTPS aux requêtes sur le port + 443.

+ + +

Quel port HTTPS utilise-t-il ?

+

Vous pouvez associer le protocole HTTPS à n'importe quel port, mais le port +standard est le port 443, que tout navigateur compatible HTTPS va utiliser par +défaut. Vous pouvez forcer votre navigateur à utiliser un port différent en le +précisant dans l'URL. Par exemple, si votre serveur est configuré pour +servir des pages en HTTPS sur le port 8080, vous pourrez y accéder par +l'adresse https://example.com:8080/.

+ + +

Comment s'exprimer en langage HTTPS à des fins +de test ?

+

Alors que vous utilisez simplement

+ +

$ telnet localhost 80
+ GET / HTTP/1.0

+ +

pour tester facilement Apache via HTTP, les choses ne sont pas si + simples pour HTTPS à cause du protocole SSL situé entre TCP et HTTP. + La commande OpenSSL s_client vous permet cependant + d'effectuer un test similaire via HTTPS :

+ +

$ openssl s_client -connect localhost:443 -state -debug
+ GET / HTTP/1.0

+ +

Avant la véritable réponse HTTP, vous recevrez des informations + détaillées à propos de l'établissement de la connexion SSL. Si vous + recherchez un client en ligne de commande à usage plus général qui comprend + directement HTTP et HTTPS, qui peut effectuer des opérations GET et POST, + peut utiliser un mandataire, supporte les requêtes portant sur une partie + d'un fichier (byte-range), etc..., vous devriez vous tourner vers + l'excellent outil cURL. Grâce à lui, + vous pouvez vérifier si Apache répond correctement aux requêtes via + HTTP et HTTPS comme suit :

+ +

$ curl http://localhost/
+ $ curl https://localhost/

+ + +

Pourquoi la communication se bloque-t-elle lorsque je +me connecte à mon serveur Apache configuré pour SSL ?

+

Ceci peut arriver si vous vous connectez à un serveur HTTPS (ou à +un serveur virtuel) via HTTP (par exemple, en utilisant +http://example.com/ au lieu de https://example.com). +Cela peut aussi arriver en essayant de vous connecter via HTTPS à un +serveur HTTP (par exemple, en utilisant https://example.com/ +avec un serveur qui ne supporte pas HTTPS, ou le supporte, mais sur un +port non standard). Assurez-vous que vous vous connectez bien à un +serveur (virtuel) qui supporte SSL.

+ + +

Pourquoi, lorsque je tente d'accéder en HTTPS à mon +serveur Apache+mod_ssl fraîchement installé, l'erreur ``Connection Refused'' +s'affiche-t-elle ?

+

Une configuration incorrecte peut provoquer ce type d'erreur. +Assurez-vous que vos directives Listen s'accordent avec vos directives + <VirtualHost>. Si + l'erreur persiste, recommencez depuis le début en restaurant la + configuration par défaut fournie parmod_ssl.

+ + +

Pourquoi les variables SSL_XXX +ne sont-elles pas disponibles dans mes scripts CGI et SSI ?

+

Assurez-vous que la directive ``SSLOptions +StdEnvVars'' est +bien présente dans le contexte de vos requêtes CGI/SSI.

+ + +

Comment puis-je basculer entre les protocoles HTTP et +HTTPS dans les hyperliens relatifs ?

+ +

Normalement, pour basculer entre HTTP et HTTPS, vous devez utiliser des +hyperliens pleinement qualifiés (car vous devez modifier le schéma de l'URL). +Cependant, à l'aide du module mod_rewrite, vous pouvez +manipuler des hyperliens relatifs, pour obtenir le même effet.

+ 
RewriteEngine on
+RewriteRule   "^/(.*)_SSL$"   "https://%{SERVER_NAME}/$1" [R,L]
+RewriteRule   "^/(.*)_NOSSL$" "http://%{SERVER_NAME}/$1"  [R,L]
+ + +

Ce jeu de règles rewrite vous permet d'utiliser des hyperliens de la + forme <a href="document.html_SSL"> pour passer en HTTPS + dans les liens relatifs. (Remplacez SSL par NOSSL pour passer en HTTP.)

+ +
top
+
+

Certificats

+ + +

Qu'est-ce qu'un clé privée RSA, un certificat, +une demande de signature de certificat (CSR) ?

+

Un fichier de clé privée RSA est un fichier numérique que vous pouvez +utiliser pour déchiffrer des messages que l'on vous a envoyés. Il a son +pendant à caractère public que vous pouvez distribuer (par le biais de votre +certificat), ce qui permet aux utilisateurs de chiffrer les messages qu'ils +vous envoient.

+

Une Demande de Signature de Certificat (CSR) est un fichier numérique + qui contient votre clé publique et votre nom. La CSR doit être envoyée à + une Autorité de Certification (CA), qui va la convertir en vrai certificat + en la signant.

+

Un certificat contient votre clé publique RSA, votre nom, le nom + de la CA, et est signé numériquement par cette dernière. Les navigateurs + qui reconnaissent la CA peuvent vérifier la signature du certificat, et + ainsi en extraire votre clé publique RSA. Ceci leur permet de vous envoyer + des messages chiffrés que vous seul pourrez déchiffrer.

+

Se référer au chapitre Introduction + pour une description générale du protocole SSL.

+ + +

Y a-t-il une différence au démarrage entre un serveur +Apache non SSL et un serveur Apache supportant SSL ?

+

Oui. En général, avec ou sans mod_ssl intégré, le démarrage +d'Apache ne présente pas de différences. Cependant, si votre fichier de clé +privée SSL possède un mot de passe, vous devrez le taper au démarrage +d'Apache.

+ +

Devoir entrer manuellement le mot de passe au démarrage du serveur peut + poser quelques problèmes - par exemple, quand le serveur est démarré au + moyen de scripts au lancement du système. Dans ce cas, vous pouvez suivre + les étapes ci-dessous pour supprimer le + mot de passe de votre clé privée. Gardez à l'esprit qu'agir ainsi augmente + les risques de sécurité - agissez avec précaution !

+ + +

Comment créer un certificat auto-signé SSL à des +fins de test ?

+
    +
  1. Vérifiez qu'OpenSSL est installé et l'exécutable openssl dans votre + PATH.
    +
    +
    2. +
  2. Exécuter la commande suivante pour créer les fichiers + server.key et server.crt :
    + $ openssl req -new -x509 -nodes -out server.crt + -keyout server.key
    + Ces fichiers seront utilisés comme suit dans votre + httpd.conf : + 
    SSLCertificateFile    "/path/to/this/server.crt"
+SSLCertificateKeyFile "/path/to/this/server.key"
    + +
    3. +
  3. Il est important de savoir que le fichier server.key n'a + pas de mot de passe. Pour ajouter un mot de passe à la clé, vous + devez exécuter la commande suivante et confirmer le mot de passe comme + demandé.
    +

    $ openssl rsa -des3 -in server.key -out + server.key.new
    + $ mv server.key.new server.key

    + Sauvegardez le fichier server.key ainsi que son mot de + passe en lieu sûr. +
    4. +
+ + +

Comment créer un vrai certificat SSL ?

+

Voici la marche à suivre pas à pas :

+
    +
  1. Assurez-vous qu'OpenSSL est bien installé et dans votre PATH. +
    +
    +
    2. +
  2. Créez une clé privée RSA pour votre serveur Apache + (elle sera au format PEM et chiffrée en Triple-DES):
    +
    + $ openssl genrsa -des3 -out server.key 2048
    +
    + Enregistrez le fichier server.key et le mot de passe + éventuellement défini en lieu sûr. + Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la + commande :
    + +
    + $ openssl rsa -noout -text -in server.key
    +
    + Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée + (non recommandé) de clé privée RSA avec :
    +
    + $ openssl rsa -in server.key -out server.key.unsecure
    +
    + +
    3. +
  3. Créez une Demande de signature de Certificat (CSR) à l'aide de la + clé privée précédemment générée (la sortie sera au format PEM):
    +
    + $ openssl req -new -key server.key -out server.csr
    +
    + Vous devez entrer le Nom de Domaine Pleinement Qualifié + ("Fully Qualified Domain Name" ou FQDN) de votre serveur lorsqu'OpenSSL + vous demande le "CommonName", c'est à dire que si vous générez une CSR + pour un site web auquel on accèdera par l'URL + https://www.foo.dom/, le FQDN sera "www.foo.dom". Vous + pouvez afficher les détails de ce CSR avec :
    + +
    + $ openssl req -noout -text -in server.csr
    +
    +
    4. +
  4. Vous devez maintenant envoyer la CSR à une Autorité de Certification + (CA), afin que cette dernière puisse la signer. Une fois la CSR signée, + vous disposerez d'un véritable certificat que vous pourrez utiliser avec + Apache. Vous pouvez faire signer votre CSR par une CA commerciale ou par + votre propre CA.
    + Les CAs commerciales vous demandent en général de leur envoyer la CSR + par l'intermédiaire d'un formulaire web, de régler le montant de la + signature, puis vous envoient un certificat signé que vous pouvez + enregistrer dans un fichier server.crt. + + Pour plus de détails sur la manière de créer sa propre CA, et de + l'utiliser pour signer une CSR, voir ci-dessous.
    + + Une fois la CSR signée, vous pouvez afficher les détails du certificat + comme suit :
    +
    + $ openssl x509 -noout -text -in server.crt
    + +
    5. +
  5. Vous devez maintenant disposer de deux fichiers : + server.key et server.crt. Ils sont précisés dans + votre fichier httpd.conf comme suit : + 
    SSLCertificateFile    "/path/to/this/server.crt"
+SSLCertificateKeyFile "/path/to/this/server.key"
    + + Le fichier server.csr n'est plus nécessaire. +
    6. + +
+ + +

Comment créer et utiliser sa propre Autorité de +certification (CA) ?

+

La solution la plus simple consiste à utiliser les scripts + CA.sh ou CA.pl fournis avec OpenSSL. De + préférence, utilisez cette solution, à moins que vous ayez de bonnes + raisons de ne pas le faire. Dans ce dernier cas, vous pouvez créer un + certificat auto-signé comme suit :

+ +
    +
  1. Créez une clé privée RSA pour votre serveur + (elle sera au format PEM et chiffrée en Triple-DES) :
    +
    + $ openssl genrsa -des3 -out server.key 2048
    +
    + Sauvegardez le fichier server.key et le mot de passe + éventuellement défini en lieu sûr. + Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la + commande :
    +
    + $ openssl rsa -noout -text -in server.key
    +
    + Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée + (non recommandé) de cette clé privée RSA avec :
    +
    + $ openssl rsa -in server.key -out server.key.unsecure
    +
    +
    2. +
  2. Créez un certificat auto-signé (structure X509) à l'aide de la clé RSA + que vous venez de générer (la sortie sera au format PEM) :
    +
    + $ openssl req -new -x509 -nodes -sha1 -days 365 + -key server.key -out server.crt -extensions usr_cert
    +
    + Cette commande signe le certificat du serveur et produit un fichier + server.crt. Vous pouvez afficher les détails de ce + certificat avec :
    +
    + $ openssl x509 -noout -text -in server.crt
    +
    +
    3. +
+ + +

Comment modifier le mot de passe +de ma clé privée ?

+

Vous devez simplement lire la clé avec l'ancien mot de passe et la +réécrire en spécifiant le nouveau mot de passe. Pour cela, vous pouvez +utiliser les commandes suivantes :

+ + +

$ openssl rsa -des3 -in server.key -out server.key.new
+ $ mv server.key.new server.key

+ +

La première fois qu'il vous est demandé un mot de passe PEM, vous + devez entrer l'ancien mot de passe. Ensuite, on vous demandera d'entrer + encore un mot de passe - cette fois, entrez le nouveau mot de passe. Si on + vous demande de vérifier le mot de passe, vous devrez entrer le nouveau + mot de passe une seconde fois.

+ + +

Comment démarrer Apache sans avoir à entrer de +mot de passe ?

+

L'apparition de ce dialogue au démarrage et à chaque redémarrage provient +du fait que la clé privée RSA contenue dans votre fichier server.key est +enregistrée sous forme chiffrée pour des raisons de sécurité. Le +déchiffrement de ce fichier nécessite un mot de passe, afin de pouvoir être +lu et interprété. Cependant, La suppression du mot de passe diminue le niveau de +sécurité du serveur - agissez avec précautions !

+
    +
  1. Supprimer le chiffrement de la clé privée RSA (tout en conservant une + copie de sauvegarde du fichier original) :
    +
    + $ cp server.key server.key.org
    + $ openssl rsa -in server.key.org -out server.key
    + +
    +
    2. +
  2. Assurez-vous que le fichier server.key n'est lisible que par root :
    +
    + $ chmod 400 server.key
    +
    +
    3. +
+ +

Maintenant, server.key contient une copie non chiffrée de + la clé. Si vous utilisez ce fichier pour votre serveur, il ne vous + demandera plus de mot de passe. CEPENDANT, si quelqu'un arrive à obtenir + cette clé, il sera en mesure d'usurper votre identité sur le réseau. + Vous DEVEZ par conséquent vous assurer que seuls root ou le serveur web + peuvent lire ce fichier (de préférence, démarrez le serveur web sous + root et faites le s'exécuter sous un autre utilisateur, en n'autorisant + la lecture de la clé que par root).

+ +

Une autre alternative consiste à utiliser la directive + ``SSLPassPhraseDialog exec:/chemin/vers/programme''. Gardez + cependant à l'esprit que ce n'est bien entendu ni plus ni moins + sécurisé.

+ + +

Comment vérifier si une clé privée correspond bien +à son certificat ?

+

Une clé privée contient une série de nombres. Deux de ces nombres forment la +"clé publique", les autres appartiennent à la "clé privée". Les bits de la +"clé publique" sont inclus quand vous générez une CSR, et font par +conséquent partie du certificat associé.

+

Pour vérifier que la clé publique contenue dans votre certificat + correspond bien à la partie publique de votre clé privée, il vous suffit + de comparer ces nombres. Pour afficher le certificat et la clé, + utilisez cette commande :

+ +

$ openssl x509 -noout -text -in server.crt
+ $ openssl rsa -noout -text -in server.key

+ +

Les parties `modulus' et `public exponent' doivent être identiques dans + la clé et le certificat. Comme le `public exponent' est habituellement + 65537, et comme il est difficile de vérifier visuellement que les nombreux + nombres du `modulus' sont identiques, vous pouvez utiliser l'approche + suivante :

+ +

$ openssl x509 -noout -modulus -in server.crt | openssl md5
+ $ openssl rsa -noout -modulus -in server.key | openssl md5

+ +

Il ne vous reste ainsi que deux nombres relativement courts à comparer. + Il est possible, en théorie que ces deux nombres soient les mêmes, sans que + les nombres du modulus soient identiques, mais les chances en sont infimes.

+

Si vous souhaitez vérifier à quelle clé ou certificat appartient une CSR + particulière, vous pouvez effectuer le même calcul + sur la CSR comme suit :

+ +

$ openssl req -noout -modulus -in server.csr | openssl md5

+ + +

Comment convertir un certificat du format PEM +au format DER ?

+

Le format des certificats par défaut pour OpenSSL est le format PEM, +qui est tout simplement un format DER codé en Base64, avec des lignes +d'en-têtes et des annotations. Certaines applications, comme +Microsoft Internet Explorer, ont besoin d'un certificat au format DER de base. +Vous pouvez convertir un fichier PEM cert.pem en son équivalent +au format DER cert.der à l'aide de la commande suivante : +$ openssl x509 -in cert.pem -out cert.der +-outform DER

+ + +

Pourquoi les navigateurs se plaignent-ils de ne pas pouvoir +vérifier mon certificat de serveur ?

+ +

Ceci peut se produire si votre certificat de serveur est signé + par une autorité de certification intermédiaire. Plusieurs CAs, + comme Verisign ou Thawte, ont commencé à signer les certificats avec + des certificats intermédiaires au lieu de leur certificat racine.

+ +

Les certificats de CA intermédiaires se situe à un niveau + intermédiaire entre le certificat racine de la CA (qui est installé dans les + navigateurs) et le certificat du serveur (que vous avez installé sur + votre serveur). Pour que le navigateur puisse traverser et vérifier + la chaîne de confiance depuis le certificat du serveur jusqu'au + certificat racine, il faut lui fournir les certificats + intermédiaires. Les CAs devraient pouvoir fournir de tels + paquetages de certificats intermédiaires à installer sur les + serveurs.

+ +

Vous devez inclure ces certificats intermédiaires via la + directive SSLCertificateChainFile.

+ +
top
+
+

Le protocole SSL

+ + +

Pourquoi de nombreuses et aléatoires erreurs de +protocole SSL apparaissent-elles en cas de forte charge du serveur ?

+

Ce problème peut avoir plusieurs causes, mais la principale réside dans le +cache de session SSL défini par la directive +SSLSessionCache. Le cache de session +DBM est souvent à la source du problème qui peut être résolu en utilisant le +cache de session SHM (ou en n'utilisant tout simplement pas de cache).

+ + +

Pourquoi la charge de mon serveur est-elle plus +importante depuis qu'il sert des ressources chiffrées en SSL ?

+

SSL utilise un procédé de chiffrement fort qui nécessite la manipulation +d'une quantité très importante de nombres. Lorsque vous effectuez une requête +pour une page web via HTTPS, tout (même les images) est chiffré avant d'être +transmis. C'est pourquoi un accroissement du traffic HTTPS entraîne une +augmentation de la charge.

+ + +

Pourquoi les connexions en HTTPS à mon serveur +prennent-elles parfois jusqu'à 30 secondes pour s'établir ?

+

Ce problème provient en général d'un périphérique /dev/random +qui bloque l'appel système read(2) jusqu'à ce que suffisamment d'entropie +soit disponible pour servir la requête. Pour plus d'information, se référer au +manuel de référence de la directive +SSLRandomSeed.

+ + +

Quels sont les algorithmes de chiffrement +supportés par mod_ssl ?

+

En général, tous les algorithmes de chiffrement supportés par la version +d'OpenSSL installée, le sont aussi par mod_ssl. La liste des +algorithmes disponibles peut dépendre de la manière dont vous avez installé +OpenSSL. Typiquement, au moins les algorithmes suivants sont supportés :

+ +
    +
  1. RC4 avec SHA1
    2. +
  2. AES avec SHA1
    3. +
  3. Triple-DES avec SHA1
    4. +
+ +

Pour déterminer la liste réelle des algorithmes disponibles, vous + pouvez utiliser la commande suivante :

+

$ openssl ciphers -v

+ + +

Pourquoi une erreur ``no shared cipher'' apparaît-elle +quand j'essaie d'utiliser un algorithme de chiffrement +Diffie-Hellman anonyme (ADH) ?

+

Par défaut et pour des raisons de sécurité, OpenSSl ne permet pas +l'utilisation des algorithmes de chiffrements ADH. Veuillez vous informer +sur les effets pervers potentiels si vous choisissez d'activer le support +de ces algorithmes de chiffrements.

+

Pour pouvoir utiliser les algorithmes de chiffrements Diffie-Hellman +anonymes (ADH), vous devez compiler OpenSSL avec +``-DSSL_ALLOW_ADH'', puis ajouter ``ADH'' à votre +directive SSLCipherSuite.

+ + +

Pourquoi une erreur ``no shared cipher'' +apparaît-elle lorsqu'on se connecte à mon serveur +fraîchement installé ?

+

Soit vous avez fait une erreur en définissant votre directive +SSLCipherSuite (comparez-la avec +l'exemple préconfiguré dans extra/httpd-ssl.conf), soit vous avez +choisi d'utiliser des algorithmes DSA/DH au lieu de RSA lorsque vous avez +généré votre clé privée, et avez ignoré ou êtes passé outre les +avertissements. Si vous avez choisi DSA/DH, votre serveur est incapable de +communiquer en utilisant des algorithmes de chiffrements SSL basés sur RSA +(du moins tant que vous n'aurez pas configuré une paire clé/certificat RSA +additionnelle). Les navigateurs modernes tels que NS ou IE ne peuvent +communiquer par SSL qu'avec des algorithmes RSA. C'est ce qui provoque l'erreur +"no shared ciphers". Pour la corriger, générez une nouvelle paire +clé/certificat pour le serveur en utilisant un algorithme de chiffrement +RSA.

+ + +

Pourquoi ne peut-on pas utiliser SSL avec des hôtes +virtuels identifiés par un nom et non par une adresse IP ?

+

La raison est très technique, et s'apparente au problème de la primauté de +l'oeuf ou de la poule. La couche du protocole SSL se trouve en dessous de la +couche de protocole HTTP qu'elle encapsule. Lors de l'établissement d'une +connexion SSL (HTTPS), Apache/mod_ssl doit négocier les paramètres du +protocole SSL avec le client. Pour cela, mod_ssl doit consulter la +configuration du serveur virtuel (par exemple, il doit accéder à la suite +d'algorithmes de chiffrement, au certificat du serveur, etc...). Mais afin de +sélectionner le bon serveur virtuel, Apache doit connaître le contenu du champ +d'en-tête HTTP Host. Pour cela, il doit lire l'en-tête de la +requête HTTP. Mais il ne peut le faire tant que la négociation SSL n'est pas +terminée, or, la phase de négociation SSL a besoin du nom d'hôte contenu +dans l'en-tête de la requête. Voir la question suivante pour +contourner ce problème.

+ +

Notez que si votre certificat comporte un nom de serveur avec + caractères génériques, ou des noms de serveurs multiples dans le + champ subjectAltName, vous pouvez utiliser SSL avec les serveurs + virtuels à base de noms sans avoir à contourner ce problème.

+ + +

Est-il possible d'utiliser +l'hébergement virtuel basé sur le nom d'hôte +pour différencier plusieurs hôtes virtuels ?

+

L'hébergement virtuel basé sur le nom est une méthode très populaire + d'identification des différents hôtes virtuels. Il permet d'utiliser la + même adresse IP et le même numéro de port pour de nombreux sites + différents. Lorsqu'on se tourne vers SSL, il semble tout naturel de penser + que l'on peut appliquer la même méthode pour gérer plusieurs hôtes + virtuels SSL sur le même serveur.

+ +

C'est possible, mais seulement si on utilise une version 2.2.12 + ou supérieure du serveur web compilée avec OpenSSL + version 0.9.8j ou supérieure. Ceci est du au fait que + l'utilisation de l'hébergement virtuel à base de nom + avec SSL nécessite une fonctionnalité appelée + Indication du Nom de Serveur (Server Name Indication - SNI) que + seules les révisions les plus récentes de la + spécification SSL supportent.

+ +

Notez que si votre certificat comporte un nom de serveur avec + caractères génériques, ou des noms de serveurs multiples dans le + champ subjectAltName, vous pouvez utiliser SSL avec les serveurs + virtuels à base de noms sans avoir à contourner ce problème.

+ +

La raison en est que le protocole SSL constitue une couche séparée qui + encapsule le protocole HTTP. Aini, la session SSL nécessite une + transaction séparée qui prend place avant que la session HTTP n'ait débuté. + Le serveur reçoit une requête SSL sur l'adresse IP X et le port Y + (habituellement 443). Comme la requête SSL ne contenait aucun + en-tête Host:, le serveur n'avait aucun moyen de déterminer quel hôte virtuel SSL il + devait utiliser. En général, il utilisait le premier + qu'il trouvait et qui + correspondait à l'adresse IP et au port spécifiés.

+ +

Par contre, si vous utilisez des versions du serveur web et + d'OpenSSL qui supportent SNI, et si le navigateur du client le + supporte aussi, alors le nom d'hôte sera inclus dans la + requête SSL originale, et le serveur web pourra + sélectionner le bon serveur virtuel SSL.

+ +

Bien entendu, vous pouvez utiliser l'hébergement virtuel basé sur le nom + pour identifier de nombreux hôtes virtuels non-SSL + (tous sur le port 80 par exemple), et ne gérer qu'un seul hôte virtuel SSL + (sur le port 443). Mais dans ce cas, vous devez définir le numéro de port + non-SSL à l'aide de la directive NameVirtualHost dans ce style :

+ + 
NameVirtualHost 192.168.1.1:80
+ + +

il existe d'autres solutions alternatives comme :

+ +

Utiliser des adresses IP différentes pour chaque hôte SSL. + Utiliser des numéros de port différents pour chaque hôte SSL.

+ + +

Comment mettre en oeuvre la compression SSL ?

+

Bien que la négociation pour la compression SSL ait été définie dans la +spécification de SSLv2 et TLS, ce n'est qu'en mai 2004 que la RFC 3749 a +défini DEFLATE comme une méthode de compression standard négociable. +

+

Depuis la version 0.9.8, OpenSSL supporte cette compression par défaut +lorsqu'il est compilé avec l'option zlib. Si le client et le +serveur supportent la compression, elle sera utilisée. Cependant, la +plupart des clients essaient encore de se connecter avec un Hello SSLv2. +Comme SSLv2 ne comportait pas de table des algorithmes de compression préférés +dans sa négociation, la compression ne peut pas être négociée avec ces clients. +Si le client désactive le support SSLv2, un Hello SSLv3 ou TLS peut être +envoyé, selon la bibliothèque SSL utilisée, et la compression peut être mise +en oeuvre. Vous pouvez vérifier si un client utilise la compression SSL en +journalisant la variable %{SSL_COMPRESS_METHOD}x. +

+ + +

Lorsque j'utilise l'authentification de base sur HTTPS, +l'icône de verrouillage des navigateurs Netscape reste ouverte quand la boîte +de dialogue d'authentification apparaît. Cela signifie-t-il que les utilisateur +et mot de passe sont envoyés en clair ?

+

Non, le couple utilisateur/mot de passe est transmis sous forme chiffrée. + L'icône de chiffrement dans les navigateurs Netscape n'est pas vraiment + synchronisé avec la couche SSL/TLS. Il ne passe à l'état verrouillé + qu'au moment où la première partie des données relatives à la page web + proprement dite sont transférées, ce qui peut prêter à confusion. Le + dispositif d'authentification de base appartient à la couche HTTP, qui + est située au dessus de la couche SSL/TLS dans HTTPS. Avant tout + transfert de données HTTP sous HTTPS, la couche SSL/TLS a déjà achevé + sa phase de négociation et basculé dans le mode de communication + chiffrée. Ne vous laissez donc pas abuser par l'état de cet icône.

+ + +

Pourquoi des erreurs d'entrée/sortie apparaissent-elles +lorsqu'on se connecte via HTTPS à un serveur Apache+mod_ssl avec des +versions anciennes de +Microsoft Internet Explorer (MSIE) ?

+

La première raison en est la présence dans l'implémentation SSL de +certaines versions de MSIE de bogues subtils en rapport avec le +dispositif de "maintien en vie" (keep-alive) HTTP, et les alertes de +notification de fermeture de session SSL en cas de coupure de la +connexion au point d'entrée (socket). De plus, l'interaction entre +SSL et les fonctionnalités HTTP/1.1 pose problème avec certaines +versions de MSIE. Vous pouvez contourner ces problèmes en interdisant +à Apache l'utilisation de HTTP/1.1, les connexions avec maintien en vie +ou l'envoi de messages de notification de fermeture de session SSL aux +clients MSIE. Pour cela, vous pouvez utiliser la directive suivante +dans votre section d'hôte virtuel avec support SSL :

+ 
SetEnvIf User-Agent "MSIE [2-5]" \
+         nokeepalive ssl-unclean-shutdown \
+         downgrade-1.0 force-response-1.0
+ +

En outre, certaines versions de MSIE ont des problèmes avec des + algorithmes de chiffrement particuliers. Hélas, il n'est pas + possible d'apporter une solution spécifique à MSIE pour ces + problèmes, car les algorithmes de chiffrement sont utilisés dès la + phase de négociation SSL. Ainsi, une directive + SetEnvIf spécifique + à MSIE ne peut être d'aucun secours. Par contre, vous devrez + ajuster les paramètres généraux de manière drastique. Avant de + vous décider, soyez sûr que vos clients rencontrent vraiment des + problèmes. Dans la négative, n'effectuez pas ces ajustements car + ils affecteront tous vos clients, ceux utilisant MSIE, + mais aussi les autres.

+ + + +

Comment activer TLS-SRP ?

+

Le protocole TLS-SRP (Echange de clés sécurisé par mot de passe + pour TLS comme spécifié dans la RFC 5054) peut compléter ou même + remplacer les certificats lors du processus d'authentification des + connexions SSL. Pour utiliser TLS-SRP, spécifiez un fichier de + vérification SRP OpenSSL via la directive SSLSRPVerifierFile. Vous pouvez créer + le fichier de vérification via l'utilitaire openssl :

+

+ openssl srp -srpvfile passwd.srpv -add username +

+

Une fois ce fichier créé, vous devez le référencer dans la + configuration du serveur SSL :

+

+ SSLSRPVerifierFile /path/to/passwd.srpv +

+

Pour forcer les clients à utiliser des algorithmes de chiffrement + basés sur TLS-SRP et s'affranchissant des certificats, utilisez la + directive suivante :

+

+ SSLCipherSuite "!DSS:!aRSA:SRP" +

+ + +

Pourquoi des erreurs de négociation apparaissent +avec les clients basés sur Java lorsqu'on utilise un certificat de plus +de 1024 bits ?

+

Depuis la version 2.4.7, + mod_ssl utilise des paramètres DH qui comportent + des nombres premiers de plus de 1024 bits. Cependant, java 7 et ses versions + antérieures ne supportent que les nombres premiers DH d'une longueur + maximale de 1024 bits.

+ +

Si votre client basé sur Java s'arrête avec une exception telle + que java.lang.RuntimeException: Could not generate DH + keypair et + java.security.InvalidAlgorithmParameterException: Prime size + must be multiple of 64, and can only range from 512 to 1024 + (inclusive), et si httpd enregistre le message tlsv1 + alert internal error (SSL alert number 80) dans son journal + des erreurs (avec un LogLevel + info ou supérieur), vous pouvez soit réarranger la + liste d'algorithmes de mod_ssl via la directive SSLCipherSuite (éventuellement en + conjonction avec la directive SSLHonorCipherOrder), soit utiliser des + paramètres DH personnalisés avec un nombre + premier de 1024 bits, paramètres qui seront toujours prioritaires + par rapport à tout autre paramètre DH par défaut.

+ +

Pour générer des paramètres DH personnalisés, utilisez la + commande openssl dhparam 1024. Vous pouvez aussi + utiliser les + paramètres DH standards issus de la RFC 2409, section 6.2 :

+ 
-----BEGIN DH PARAMETERS-----
+MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
+Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
+/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
+-----END DH PARAMETERS-----
+

Ajoute les paramètres personnalisés incluant les lignes "BEGIN DH + PARAMETERS" et "END DH PARAMETERS" à la fin du premier fichier de + certificat défini via la directive SSLCertificateFile.

+ + +
top
+
+

Support de mod_ssl

+ + +

Quelles sont les sources d'informations +disponibles en cas de problème avec mod_ssl ?

+

Voici les sources d'informations disponibles ; vous devez chercher +ici en cas de problème.

+ +
+
Vous trouverez des réponses dans la Foire Aux Questions du + manuel utilisateur (ce document)
+
+ http://httpd.apache.org/docs/2.4/ssl/ssl_faq.html
+ Cherchez tout d'abord dans la foire aux questions + (ce document). Si votre question est courante, on a déjà dû y + répondre de nombreuses fois, et elle fait probablement partie + de ce document. +
+
+ + +

Qui peut-on contacter pour un support en cas de +problème avec mod_ssl ?

+

Voici toutes les possibilités de support pour mod_ssl, par ordre + de préférence. Merci d'utiliser ces possibilités + dans cet ordre - ne vous précipitez pas sur celle qui vous + paraît la plus alléchante.

+
    +
  1. Envoyez un rapport de problème à la liste de diffusion de + support des utilisateurs d'Apache httpd
    + + users@httpd.apache.org
    + C'est la deuxième manière de soumettre votre rapport de + problème. Ici aussi, vous devez d'abord vous abonner à la + liste, mais vous pourrez ensuite discuter facilement de votre + problème avec l'ensemble de la communauté d'utilisateurs + d'Apache httpd. +
    2. + +
  2. Ecrire un rapport de problème dans la base de données des + bogues
    + + http://httpd.apache.org/bug_report.html
    + C'est la dernière manière de soumettre votre rapport de + problème. Vous ne devez utiliser cette solution que si vous + avez déjà écrit aux listes de diffusion, et n'avez pas trouvé + de solution. Merci de suivre les instructions de la page + mentionnée ci-dessus avec soin. +
    3. +
+ + +

Quelles informations dois-je fournir lors +de l'écriture d'un rapport de bogue ?

+

Vous devez toujours fournir au moins les informations +suivantes :

+ +
+
Les versions d'Apache httpd et OpenSSL installées
+
La version d'Apache peut être déterminée en exécutant + httpd -v. La version d'OpenSSL peut être déterminée + en exécutant openssl version. Si Lynx est installé, + vous pouvez aussi exécuter la commandelynx -mime_header + http://localhost/ | grep Server et ainsi obtenir ces + informations en une seule fois. +
+ +
Les détails de votre installation d'Apache httpd et OpenSSL
+
A cet effet, vous pouvez fournir un fichier journal de votre + session de terminal qui montre les étapes de la configuration et + de l'installation. En cas d'impossibilité, vous devez au moins + fournir la ligne de commande configure que + vous avez utilisée. +
+ +
En cas de vidage mémoire, inclure une trace de ce qui s'est + passé
+
Si votre serveur Apache httpd fait un vidage de sa + mémoire, merci de fournir en pièce jointe un fichier contenant + une trace de la zone dédiée à la pile (voir + ci-dessous pour des informations sur la manière + de l'obtenir). Il est nécessaire de disposer de ces informations + afin de pouvoir déterminer la raison de votre vidage mémoire. +
+ +
Une description détaillée de votre problème
+ +
Ne riez pas, nous sommes sérieux ! De nombreux rapports + n'incluent pas de description de la véritable nature du problème. + Sans ces informations, il est très difficile pour quiconque de + vous aider. Donc, et c'est votre propre intérêt (vous souhaitez + que le problème soit résolu, n'est-ce pas ?), fournissez, s'il vous + plait, le maximum de détails possible. Bien entendu, vous devez + aussi inclure tout ce qui a été dit précédemment. +
+
+ + +

Un vidage mémoire s'est produit, +pouvez-vous m'aider ?

+

En général non, du moins tant que vous n'aurez pas fourni plus de +détails à propos de la localisation dans le code où Apache a effectué +son vidage mémoire. Ce dont nous avons en général besoin pour vous +aider est une trace de ce qui s'est passé (voir la question suivante). +Sans cette information, il est pratiquement impossible de déterminer +la nature du problème et de vous aider à le résoudre.

+ + +

Comment puis-je obtenir une journalisation de +ce qui s'est passé, pour m'aider à trouver la raison de ce vidage +mémoire ?

+

Vous trouverez ci-dessous les différentes étapes permettant +d'obtenir une journalisation des évènements (backtrace) :

+
    +
  1. Assurez-vous que les symboles de débogage sont disponibles, au + moins pour Apache. Pour cela, sur les plates-formes où GCC/GDB est + utilisé, vous devez compiler Apache+mod_ssl avec l'option + ``OPTIM="-g -ggdb3"''. Sur les autres plates-formes, + l'option ``OPTIM="-g"'' est un minimum. +
    2. + +
  2. Démarrez le serveur et essayez de reproduire le vidage mémoire. + A cet effet, vous pouvez utiliser une directive du style + ``CoreDumpDirectory /tmp'' pour être sûr que le + fichier de vidage mémoire puisse bien être écrit. Vous devriez + obtenir un fichier /tmp/core ou + /tmp/httpd.core. Si ce n'est pas le cas, essayez de + lancer votre serveur sous un UID autre que root. + Pour des raisons de sécurité, de nombreux + noyaux modernes de permettent pas à un processus de vider sa + mémoire une fois qu'il a accompli un setuid() (à moins + qu'il effectue un exec()) car des informations d'un + niveau privilégié pourraient être transmises en mémoire. Si + nécessaire, vous pouvez exécuter /chemin/vers/httpd -X + manuellement afin de ne pas permettre à Apache de se clôner (fork). +
    3. + +
  3. Analysez le vidage mémoire. Pour cela, exécutez + gdb /path/to/httpd /tmp/httpd.core ou une commande + similaire. Dans GDB, tout ce que vous avez à faire est d'entrer + bt, et voila, vous obtenez la backtrace. Pour les + débogueurs autres que GDB consulter le manuel correspondant. +
    4. +
+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/ssl/ssl_howto.html b/docs/manual/ssl/ssl_howto.html new file mode 100644 index 0000000..004586e --- /dev/null +++ b/docs/manual/ssl/ssl_howto.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: ssl_howto.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: ssl_howto.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/ssl/ssl_howto.html.en b/docs/manual/ssl/ssl_howto.html.en new file mode 100644 index 0000000..d5c2075 --- /dev/null +++ b/docs/manual/ssl/ssl_howto.html.en @@ -0,0 +1,449 @@ + + + + + +SSL/TLS Strong Encryption: How-To - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

SSL/TLS Strong Encryption: How-To

+
+

Available Languages:  en  | + fr 

+
+ + +

This document is intended to get you started, and get a few things +working. You are strongly encouraged to read the rest of the SSL +documentation, and arrive at a deeper understanding of the material, +before progressing to the advanced techniques.

+
+ +
top
+
+

Basic Configuration Example

+ + +

Your SSL configuration will need to contain, at minimum, the +following directives.

+ +
LoadModule ssl_module modules/mod_ssl.so
+
+Listen 443
+<VirtualHost *:443>
+    ServerName www.example.com
+    SSLEngine on
+    SSLCertificateFile "/path/to/www.example.com.cert"
+    SSLCertificateKeyFile "/path/to/www.example.com.key"
+</VirtualHost>
+ + +
top
+
+

Cipher Suites and Enforcing Strong Security

+ + + +

How can I create an SSL server which accepts strong encryption +only?

+ +

The following enables only the strongest ciphers:

+ 
SSLCipherSuite HIGH:!aNULL:!MD5
+ + +

While with the following configuration you specify a preference + for specific speed-optimized ciphers (which will be selected by + mod_ssl, provided that they are supported by the client):

+ + 
SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5
+SSLHonorCipherOrder on
+ + + +

How can I create an SSL server which accepts all types of ciphers +in general, but requires a strong ciphers for access to a particular +URL?

+ +

Obviously, a server-wide SSLCipherSuite which restricts + ciphers to the strong variants, isn't the answer here. However, + mod_ssl can be reconfigured within Location + blocks, to give a per-directory solution, and can automatically force + a renegotiation of the SSL parameters to meet the new configuration. + This can be done as follows:

+ 
# be liberal in general
+SSLCipherSuite ALL:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
+
+<Location "/strong/area">
+# but https://hostname/strong/area/ and below
+# requires strong ciphers
+SSLCipherSuite HIGH:!aNULL:!MD5
+</Location>
+ + +
top
+
+

OCSP Stapling

+ + +

The Online Certificate Status Protocol (OCSP) is a mechanism for +determining whether or not a server certificate has been revoked, and OCSP +Stapling is a special form of this in which the server, such as httpd and +mod_ssl, maintains current OCSP responses for its certificates and sends +them to clients which communicate with the server. Most certificates +contain the address of an OCSP responder maintained by the issuing +Certificate Authority, and mod_ssl can communicate with that responder to +obtain a signed response that can be sent to clients communicating with +the server.

+ +

Because the client can obtain the certificate revocation status from +the server, without requiring an extra connection from the client to the +Certificate Authority, OCSP Stapling is the preferred way for the +revocation status to be obtained. Other benefits of eliminating the +communication between clients and the Certificate Authority are that the +client browsing history is not exposed to the Certificate Authority and +obtaining status is more reliable by not depending on potentially heavily +loaded Certificate Authority servers.

+ +

Because the response obtained by the server can be reused for all clients +using the same certificate during the time that the response is valid, the +overhead for the server is minimal.

+ +

Once general SSL support has been configured properly, enabling OCSP +Stapling generally requires only very minor modifications to the httpd +configuration — the addition of these two directives:

+ + 
SSLUseStapling On
+SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"
+ + +

These directives are placed at global scope (i.e., not within a virtual +host definition) wherever other global SSL configuration directives are +placed, such as in conf/extra/httpd-ssl.conf for normal +open source builds of httpd, /etc/apache2/mods-enabled/ssl.conf +for the Ubuntu or Debian-bundled httpd, etc.

+ +

The path on the SSLStaplingCache directive +(e.g., logs/) should match the one on the +SSLSessionCache directive. This path is relative +to ServerRoot.

+ +

This particular SSLStaplingCache directive requires +mod_socache_shmcb (from the shmcb prefix on the +directive's argument). This module is usually enabled already for +SSLSessionCache or on behalf of some module other than +mod_ssl. If you enabled an SSL session cache using a +mechanism other than mod_socache_shmcb, use that alternative +mechanism for SSLStaplingCache as well. For example:

+ + 
SSLSessionCache "dbm:logs/ssl_scache"
+SSLStaplingCache "dbm:logs/ssl_stapling"
+ + +

You can use the openssl command-line program to verify that an OCSP response +is sent by your server:

+ +
$ openssl s_client -connect www.example.com:443 -status -servername www.example.com
+...
+OCSP response: 
+======================================
+OCSP Response Data:
+    OCSP Response Status: successful (0x0)
+    Response Type: Basic OCSP Response
+...
+    Cert Status: Good
+...
+ +

The following sections highlight the most common situations which require +further modification to the configuration. Refer also to the +mod_ssl reference manual.

+ +

If more than a few SSL certificates are used for the server

+ +

OCSP responses are stored in the SSL stapling cache. While the responses +are typically a few hundred to a few thousand bytes in size, mod_ssl +supports OCSP responses up to around 10K bytes in size. With more than a +few certificates, the stapling cache size (32768 bytes in the example above) +may need to be increased. Error message AH01929 will be logged in case of +an error storing a response.

+ + +

If the certificate does not point to an OCSP responder, or if a +different address must be used

+ +

Refer to the +SSLStaplingForceURL directive.

+ +

You can confirm that a server certificate points to an OCSP responder +using the openssl command-line program, as follows:

+ +
$ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http'
+OCSP - URI:http://ocsp.example.com
+ +

If the OCSP URI is provided and the web server can communicate to it +directly without using a proxy, no configuration is required. Note that +firewall rules that control outbound connections from the web server may +need to be adjusted.

+ +

If no OCSP URI is provided, contact your Certificate Authority to +determine if one is available; if so, configure it with +SSLStaplingForceURL in the virtual +host that uses the certificate.

+ + +

If multiple SSL-enabled virtual hosts are configured and OCSP +Stapling should be disabled for some

+ + +

Add SSLUseStapling Off to the virtual hosts for which OCSP +Stapling should be disabled.

+ + +

If the OCSP responder is slow or unreliable

+ +

Several directives are available to handle timeouts and errors. Refer +to the documentation for the +SSLStaplingFakeTryLater, +SSLStaplingResponderTimeout, and +SSLStaplingReturnResponderErrors +directives.

+ + +

If mod_ssl logs error AH02217

+ +
AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate!
+

In order to support OCSP Stapling when a particular server certificate is +used, the certificate chain for that certificate must be configured. If it +was not configured as part of enabling SSL, the AH02217 error will be issued +when stapling is enabled, and an OCSP response will not be provided for clients +using the certificate.

+ +

Refer to the SSLCertificateChainFile +and SSLCertificateFile for instructions +for configuring the certificate chain.

+ + +
top
+
+

Client Authentication and Access Control

+ + + +

How can I force clients to authenticate using certificates?

+ + +

When you know all of your users (eg, as is often the case on a corporate + Intranet), you can require plain certificate authentication. All you + need to do is to create client certificates signed by your own CA + certificate (ca.crt) and then verify the clients against this + certificate.

+ 
# require a client certificate which has to be directly
+# signed by our CA certificate in ca.crt
+SSLVerifyClient require
+SSLVerifyDepth 1
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+ + + +

How can I force clients to authenticate using certificates for a + particular URL, but still allow arbitrary clients to access the rest of the server?

+ + +

To force clients to authenticate using certificates for a particular URL, + you can use the per-directory reconfiguration features of + mod_ssl:

+ + 
SSLVerifyClient none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+
+<Location "/secure/area">
+SSLVerifyClient require
+SSLVerifyDepth 1
+</Location>
+ + + +

How can I allow only clients who have certificates to access a + particular URL, but allow all clients to access the rest of the server?

+ + +

The key to doing this is checking that part of the client certificate + matches what you expect. Usually this means checking all or part of the + Distinguished Name (DN), to see if it contains some known string. + There are two ways to do this, using either mod_auth_basic or + SSLRequire.

+ +

The mod_auth_basic method is generally required when + the certificates are completely arbitrary, or when their DNs have + no common fields (usually the organisation, etc.). In this case, + you should establish a password database containing all + clients allowed, as follows:

+ + 
SSLVerifyClient      none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+SSLCACertificatePath "conf/ssl.crt"
+
+<Directory "/usr/local/apache2/htdocs/secure/area">
+    SSLVerifyClient      require
+    SSLVerifyDepth       5
+    SSLOptions           +FakeBasicAuth
+    SSLRequireSSL
+    AuthName             "Snake Oil Authentication"
+    AuthType             Basic
+    AuthBasicProvider    file
+    AuthUserFile         "/usr/local/apache2/conf/httpd.passwd"
+    Require              valid-user
+</Directory>
+ + +

The password used in this example is the DES encrypted string "password". + See the SSLOptions docs for more + information.

+ +

httpd.passwd

/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
+/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
+/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
+ +

When your clients are all part of a common hierarchy, which is encoded + into the DN, you can match them more easily using SSLRequire, as follows:

+ + + 
SSLVerifyClient      none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+SSLCACertificatePath "conf/ssl.crt"
+
+<Directory "/usr/local/apache2/htdocs/secure/area">
+  SSLVerifyClient      require
+  SSLVerifyDepth       5
+  SSLOptions           +FakeBasicAuth
+  SSLRequireSSL
+  SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." \
+               and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
+</Directory>
+ + + +

How can I require HTTPS with strong ciphers, and either basic +authentication or client certificates, for access to part of the +Intranet website, for clients coming from the Internet? I still want to allow +plain HTTP access for clients on the Intranet.

+ + +

These examples presume that clients on the Intranet have IPs in the range + 192.168.1.0/24, and that the part of the Intranet website you want to allow + internet access to is /usr/local/apache2/htdocs/subarea. + This configuration should remain outside of your HTTPS virtual host, so + that it applies to both HTTPS and HTTP.

+ + 
SSLCACertificateFile "conf/ssl.crt/company-ca.crt"
+
+<Directory "/usr/local/apache2/htdocs">
+    #   Outside the subarea only Intranet access is granted
+    Require              ip 192.168.1.0/24
+</Directory>
+
+<Directory "/usr/local/apache2/htdocs/subarea">
+    #   Inside the subarea any Intranet access is allowed
+    #   but from the Internet only HTTPS + Strong-Cipher + Password
+    #   or the alternative HTTPS + Strong-Cipher + Client-Certificate
+    
+    #   If HTTPS is used, make sure a strong cipher is used.
+    #   Additionally allow client certs as alternative to basic auth.
+    SSLVerifyClient      optional
+    SSLVerifyDepth       1
+    SSLOptions           +FakeBasicAuth +StrictRequire
+    SSLRequire           %{SSL_CIPHER_USEKEYSIZE} >= 128
+    
+    #   Force clients from the Internet to use HTTPS
+    RewriteEngine        on
+    RewriteCond          "%{REMOTE_ADDR}" "!^192\.168\.1\.[0-9]+$"
+    RewriteCond          "%{HTTPS}" "!=on"
+    RewriteRule          "." "-" [F]
+    
+    #   Allow Network Access and/or Basic Auth
+    Satisfy              any
+    
+    #   Network Access Control
+    Require              ip 192.168.1.0/24
+    
+    #   HTTP Basic Authentication
+    AuthType             basic
+    AuthName             "Protected Intranet Area"
+    AuthBasicProvider    file
+    AuthUserFile         "conf/protected.passwd"
+    Require              valid-user
+</Directory>
+ + +
top
+
+

Logging

+ + +

mod_ssl can log extremely verbose debugging information + to the error log, when its LogLevel is + set to the higher trace levels. On the other hand, on a very busy server, + level info may already be too much. Remember that you can + configure the LogLevel per module to + suite your needs.

+
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/ssl/ssl_howto.html.fr.utf8 b/docs/manual/ssl/ssl_howto.html.fr.utf8 new file mode 100644 index 0000000..660a905 --- /dev/null +++ b/docs/manual/ssl/ssl_howto.html.fr.utf8 @@ -0,0 +1,489 @@ + + + + + +Chiffrement fort SSL/TLS : Mode d'emploi - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Chiffrement fort SSL/TLS : Mode d'emploi

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document doit vous permettre de démarrer et de faire fonctionner +une configuration de base. Avant de vous lancer dans l'application de +techniques avancées, il est fortement recommandé de lire le reste +de la documentation SSL afin d'en comprendre le fonctionnement de +manière plus approfondie.

+
+ +
top
+
+

Exemple de configuration basique

+ + +

Votre configuration SSL doit comporter au moins les directives +suivantes :

+ +
LoadModule ssl_module modules/mod_ssl.so
+
+Listen 443
+<VirtualHost *:443>
+    ServerName www.example.com
+    SSLEngine on
+    SSLCertificateFile "/path/to/www.example.com.cert"
+    SSLCertificateKeyFile "/path/to/www.example.com.key"
+</VirtualHost>
+ + +
top
+
+

Suites de chiffrement et mise en application de la sécurité +de haut niveau

+ + + + +

Comment créer un serveur SSL qui n'accepte +que le chiffrement fort ?

+ +

Les directives suivantes ne permettent que les + chiffrements de plus haut niveau :

+ 
SSLCipherSuite HIGH:!aNULL:!MD5
+ + +

Avec la configuration qui suit, vous indiquez une préférence pour + des algorityhmes de chiffrement spécifiques optimisés en matière de + rapidité (le choix final sera opéré par mod_ssl, dans la mesure ou le + client les supporte) :

+ + 
SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5
+SSLHonorCipherOrder on
+ + + +

Comment créer un serveur qui accepte tous les types de +chiffrement en général, mais exige un chiffrement fort pour pouvoir +accéder à une URL particulière ?

+ +

Dans ce cas bien évidemment, une directive SSLCipherSuite au niveau du serveur principal + qui restreint le choix des suites de chiffrement aux versions les plus + fortes ne conviendra pas. mod_ssl peut cependant être + reconfiguré au sein de blocs Location qui permettent + d'adapter la configuration générale à un répertoire spécifique ; + mod_ssl peut alors forcer automatiquement une + renégociation des paramètres SSL pour parvenir au but recherché. + Cette configuration peut se présenter comme suit :

+ 
# soyons très tolérant a priori
+SSLCipherSuite ALL:!aNULL:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP:+eNULL
+
+<Location "/strong/area">
+# sauf pour https://hostname/strong/area/ et ses sous-répertoires
+# qui exigent des chiffrements forts
+SSLCipherSuite HIGH:!aNULL:!MD5
+</Location>
+ + +
top
+
+

Agrafage OCSP

+ + +

Le protocole de contrôle du statut des certificats en ligne (Online +Certificate Status Protocol - OCSP) est un mécanisme permettant de +déterminer si un certificat a été révoqué ou non, et l'agrafage OCSP en +est une fonctionnalité particulière par laquelle le serveur, par exemple +httpd et mod_ssl, maintient une liste des réponses OCSP actuelles pour +ses certificats et l'envoie aux clients qui communiquent avec lui. La +plupart des certificats contiennent l'adresse d'un répondeur OCSP maintenu +par l'Autorité de Certification (CA) spécifiée, et mod_ssl peut requérir +ce répondeur pour obtenir une réponse signée qui peut être envoyée aux +clients qui communiquent avec le serveur.

+ +

L'agrafage OCSP est la méthode la plus performante pour obtenir le +statut d'un certificat car il est disponible au niveau du serveur, et le +client n'a donc pas besoin d'ouvrir une nouvelle connexion vers +l'autorité de certification. Autres avantages de l'absence de +communication entre le client et l'autorité de certification : +l'autorité de certification n'a pas accès à l'historique de navigation +du client, et l'obtention du statut du certificat est plus efficace car +elle n'est plus assujettie à une surcharge éventuelle des serveurs de +l'autorité de certification.

+ +

La charge du serveur est moindre car la réponse qu'il a obtenu du +répondeur OCSP peut être réutilisée par tous les clients qui utilisent +le même certificat dans la limite du temps de validité de la réponse.

+ +

Une fois le support général SSL correctement configuré, l'activation +de l'agrafage OCSP ne requiert que des modifications mineures +à la configuration de httpd et il suffit en général de l'ajout de ces +deux directives :

+ + 
SSLUseStapling On
+SSLStaplingCache "shmcb:ssl_stapling(32768)"
+ + +

Ces directives sont placées de façon à ce qu'elles aient une portée +globale (et particulièrement en dehors de toute section VirtualHost), le +plus souvent où sont placées les autres directives de configuration +globales SSL, comme conf/extra/httpd-ssl.conf pour les +installations de httpd à partir des sources, ou +/etc/apache2/mods-enabled/ssl.conf pour Ubuntu ou Debian, +etc...

+ +

Le chemin spécifié par la directive +SSLStaplingCache (par exemple logs/) +doit être le même que celui spécifié par la directive +SSLSessionCache. Ce chemin est relatif au chemin +spécifié par la directive ServerRoot.

+ +

Cette directive SSLStaplingCache particulière +nécessite le chargement du module mod_socache_shmcb (à +cause du préfixe shmcb de son argument). Ce module est en +général déjà activé pour la directive +SSLSessionCache, ou pour des modules autres que +mod_ssl. Si vous activez un cache de session SSL +utilisant un mécanisme autre que mod_socache_shmcb, +utilisez aussi ce mécanisme alternatif pour la directive +SSLStaplingCache. Par exemple :

+ + 
SSLSessionCache "dbm:ssl_scache"
+SSLStaplingCache "dbm:ssl_stapling"
+ + +

Vous pouvez utiliser la commande openssl pour vérifier que votre +serveur envoie bien une réponse OCSP :

+ +
$ openssl s_client -connect www.example.com:443 -status -servername www.example.com
+...
+OCSP response: 
+======================================
+OCSP Response Data:
+    OCSP Response Status: successful (0x0)
+    Response Type: Basic OCSP Response
+...
+    Cert Status: Good
+...
+ +

Les sections suivantes explicitent les situations courantes qui +requièrent des modifications supplémentaires de la configuration. Vous +pouvez aussi vous référer au manuel de référence de +mod_ssl.

+ +

Si l'on utilise plus que quelques certificats SSL pour le serveur

+ +

Les réponses OCSP sont stockées dans le cache d'agrafage SSL. Alors +que les réponses ont une taille de quelques centaines à quelques +milliers d'octets, mod_ssl supporte des réponses d'une taille jusqu'à +environ 10 ko. Dans notre cas, le nombre de certificats est conséquent +et la taille du cache (32768 octets dans l'exemple ci-dessus) doit être +augmentée. En cas d'erreur lors du stockage d'une réponse, le +message AH01929 sera enregistré dans le journal.

+ + +

Si le certificat ne spécifie pas de répondeur OCSP, ou si une +adresse différente doit être utilisée

+ +

Veuillez vous référer à la documentation de la directive SSLStaplingForceURL.

+ +

Vous pouvez vérifier si un certificat spécifie un répondeur OCSP en +utilisant la commande openssl comme suit :

+ +
$ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http'
+OCSP - URI:http://ocsp.example.com
+ +

Si un URI OCSP est fourni et si le serveur web peut communiquer +directement avec lui sans passer par un mandataire, aucune modification +supplémentaire de la configuration n'est requise. Notez que les règles +du pare-feu qui contrôlent les connexions sortantes en provenance du +serveur web devront peut-être subir quelques ajustements.

+ +

Si aucun URI OCSP n'est fourni, contactez votre autorité de +certification pour savoir s'il en existe une ; si c'est le +cas, utilisez la directive SSLStaplingForceURL pour la spécifier dans +la configuration du serveur virtuel qui utilise le certificat.

+ + +

Si plusieurs serveurs virtuels sont configurés pour utiliser SSL +et si l'agrafage OCSP doit être désactivé pour certains d'entre eux

+ + +

Ajoutez la directive SSLUseStapling Off à la +configuration des serveurs virtuels pour lesquels l'agrafage OCSP doit +être désactivé.

+ + +

Si le répondeur OCSP est lent ou instable

+ +

De nombreuses directives permettent de gérer les temps de réponse et +les erreurs. Référez-vous à la documentation de SSLStaplingFakeTryLater, SSLStaplingResponderTimeout, et SSLStaplingReturnResponderErrors.

+ + +

Si mod_ssl enregistre l'erreur AH02217 dans le journal

+ +
AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate!
+

Afin de pouvoir supporter l'agrafage OCSP lorsqu'un certificat de +serveur particulier est utilisé, une chaîne de certification pour ce +certificat doit être spécifiée. Si cela n'a pas été fait lors de +l'activation de SSL, l'erreur AH02217 sera enregistrée lorsque +l'agrafage OCSP sera activé, et les clients qui utilisent le certificat +considéré ne recevront pas de réponse OCSP.

+ +

Veuillez vous référer à la documentation des directives SSLCertificateChainFile et SSLCertificateFile pour spécifier une +chaîne de certification.

+ + +
top
+
+

Authentification du client et contrôle d'accès

+ + + +

Comment forcer les clients +à s'authentifier à l'aide de certificats ? +

+ + +

Lorsque vous connaissez tous vos clients (comme c'est en général le cas + au sein d'un intranet d'entreprise), vous pouvez imposer une + authentification basée uniquement sur les certificats. Tout ce dont vous + avez besoin pour y parvenir est de créer des certificats clients signés par + le certificat de votre propre autorité de certification + (ca.crt), et d'authentifier les clients à l'aide de ces + certificats.

+ 
# exige un certificat client signé par le certificat de votre CA
+# contenu dans ca.crt
+SSLVerifyClient require
+SSLVerifyDepth 1
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+ + + +

Comment forcer les clients +à s'authentifier à l'aide de certificats pour une URL particulière, +mais autoriser quand-même tout client anonyme +à accéder au reste du serveur ?

+ + +

Pour forcer les clients à s'authentifier à l'aide de certificats pour une +URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration +de mod_ssl en fonction du répertoire :

+ + 
SSLVerifyClient none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+
+<Location "/secure/area">
+SSLVerifyClient require
+SSLVerifyDepth 1
+</Location>
+ + + +

Comment n'autoriser l'accès à une URL +particulière qu'aux clients qui possèdent des certificats, mais autoriser +l'accès au reste du serveur à tous les clients ?

+ + +

La clé du problème consiste à vérifier si une partie du certificat + client correspond à ce que vous attendez. Cela signifie en général + consulter tout ou partie du nom distinctif (DN), afin de vérifier s'il + contient une chaîne connue. Il existe deux méthodes pour y parvenir ; + on utilise soit le module mod_auth_basic, soit la + directive SSLRequire.

+ +

La méthode du module mod_auth_basic est en général + incontournable lorsque les certificats ont un contenu arbitraire, ou + lorsque leur DN ne contient aucun champ connu + (comme l'organisation, etc...). Dans ce cas, vous devez construire une base + de données de mots de passe contenant tous les clients + autorisés, comme suit :

+ + 
SSLVerifyClient      none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+SSLCACertificatePath "conf/ssl.crt"
+
+<Directory "/usr/local/apache2/htdocs/secure/area">
+SSLVerifyClient      require
+    SSLVerifyDepth       5
+    SSLOptions           +FakeBasicAuth
+    SSLRequireSSL
+    AuthName             "Snake Oil Authentication"
+    AuthType             Basic
+    AuthBasicProvider    file
+    AuthUserFile         "/usr/local/apache2/conf/httpd.passwd"
+    Require              valid-user
+</Directory>
+ + + +

Le mot de passe utilisé dans cet exemple correspond à la chaîne de + caractères "password" chiffrée en DES. Voir la documentation de la + directive SSLOptions pour + plus de détails.

+ +

httpd.passwd

/C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
+/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
+/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
+ +

Lorsque vos clients font tous partie d'une même hiérarchie, ce qui + apparaît dans le DN, vous pouvez les authentifier plus facilement en + utilisant la directive SSLRequire, comme suit :

+ + + 
SSLVerifyClient      none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+SSLCACertificatePath "conf/ssl.crt"
+
+<Directory "/usr/local/apache2/htdocs/secure/area">
+  SSLVerifyClient      require
+  SSLVerifyDepth       5
+  SSLOptions           +FakeBasicAuth
+  SSLRequireSSL
+  SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." \
+               and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
+</Directory>
+ + + +

Comment imposer HTTPS avec chiffrements forts, +et soit authentification de base, soit possession de certificats clients, +pour l'accès à une partie de l'Intranet, pour les clients en +provenance de l'Internet ? Je souhaite quand-même autoriser l'accès en HTTP +aux clients de l'intranet.

+ + +

On suppose dans ces exemples que les clients de l'intranet ont des + adresses IP dans la gamme 192.168.1.0/24, et que la partie de l'intranet + à laquelle vous voulez autoriser l'accès depuis l'Internet est + /usr/local/apache2/htdocs/subarea. Ces lignes de configuration + doivent se trouver en dehors de votre hôte virtuel HTTPS, afin qu'elles + s'appliquent à la fois à HTTP et HTTPS.

+ + 
SSLCACertificateFile "conf/ssl.crt/company-ca.crt"
+
+<Directory "/usr/local/apache2/htdocs">
+#   En dehors de subarea, seul l'accès depuis l'intranet est
+#   autorisé
+    Require              ip 192.168.1.0/24
+</Directory>
+
+<Directory "/usr/local/apache2/htdocs/subarea">
+#   Dans subarea, tout accès depuis l'intranet est autorisé
+#   mais depuis l'Internet, seul l'accès par HTTPS + chiffrement fort + Mot de passe
+#   ou HTTPS + chiffrement fort + certificat client n'est autorisé.
+
+#   Si HTTPS est utilisé, on s'assure que le niveau de chiffrement est fort.
+#   Autorise en plus les certificats clients comme une alternative à
+#   l'authentification basique.
+    SSLVerifyClient      optional
+    SSLVerifyDepth       1
+    SSLOptions           +FakeBasicAuth +StrictRequire
+    SSLRequire           %{SSL_CIPHER_USEKEYSIZE} >= 128
+    
+    #   ON oblige les clients venant d'Internet à utiliser HTTPS
+    RewriteEngine        on
+    RewriteCond          "%{REMOTE_ADDR}" "!^192\.168\.1\.[0-9]+$"
+    RewriteCond          "%{HTTPS}" "!=on"
+    RewriteRule          "." "-" [F]
+    
+    #   On permet l'accès soit sur les critères réseaux, soit par authentification Basique
+    Satisfy              any
+    
+    #   Contrôle d'accès réseau
+    Require              ip 192.168.1.0/24
+    
+    #   Configuration de l'authentification HTTP Basique
+    AuthType             basic
+    AuthName             "Protected Intranet Area"
+    AuthBasicProvider    file
+    AuthUserFile         "conf/protected.passwd"
+    Require              valid-user
+</Directory>
+ + +
top
+
+

Journalisation

+ + +

mod_ssl peut enregistrer des informations de + débogage très verbeuses dans le journal des erreurs, lorsque sa + directive LogLevel est définie + à des niveaux de trace élevés. Par contre, sur un serveur très + sollicité, le niveau info sera probablement déjà trop + élevé. Souvenez-vous que vous pouvez configurer la directive + LogLevel par module afin de + pourvoir à vos besoins.

+
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/ssl/ssl_intro.html b/docs/manual/ssl/ssl_intro.html new file mode 100644 index 0000000..25de340 --- /dev/null +++ b/docs/manual/ssl/ssl_intro.html @@ -0,0 +1,13 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: ssl_intro.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: ssl_intro.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: ssl_intro.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/ssl/ssl_intro.html.en b/docs/manual/ssl/ssl_intro.html.en new file mode 100644 index 0000000..bdd4792 --- /dev/null +++ b/docs/manual/ssl/ssl_intro.html.en @@ -0,0 +1,672 @@ + + + + + +SSL/TLS Strong Encryption: An Introduction - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

SSL/TLS Strong Encryption: An Introduction

+
+

Available Languages:  en  | + fr  | + ja 

+
+ + +

As an introduction this chapter is aimed at readers who are familiar +with the Web, HTTP, and Apache, but are not security experts. It is not +intended to be a definitive guide to the SSL protocol, nor does it discuss +specific techniques for managing certificates in an organization, or the +important legal issues of patents and import and export restrictions. +Rather, it is intended to provide a common background to mod_ssl users by pulling together various concepts, definitions, +and examples as a starting point for further exploration.

+
+ +
top
+
+

Cryptographic Techniques

+ +

Understanding SSL requires an understanding of cryptographic +algorithms, message digest functions (aka. one-way or hash functions), and +digital signatures. These techniques are the subject of entire books (see +for instance [AC96]) and provide the basis for privacy, +integrity, and authentication.

+ +

Cryptographic Algorithms

+ +

Suppose Alice wants to send a message to her bank to transfer some + money. Alice would like the message to be private, since it will + include information such as her account number and transfer amount. One + solution is to use a cryptographic algorithm, a technique that would + transform her message into an encrypted form, unreadable until it is + decrypted. Once in this form, the message can only be + decrypted by using a secret key. Without the key the message is useless: + good cryptographic algorithms make it so difficult + for intruders to decode the original text that it isn't worth their + effort.

+ +

There are two categories of cryptographic algorithms: conventional + and public key.

+ +
+
Conventional cryptography
+
also known as symmetric cryptography, requires the sender and + receiver to share a key: a secret piece of information that may be + used to encrypt or decrypt a message. As long as this key is kept + secret, nobody other than the sender or recipient can read the message. + If Alice and the bank know a secret key, then they can send each other + private messages. The task of sharing a key between sender and recipient + before communicating, while also keeping it secret from others, can be + problematic.
+ +
Public key cryptography
+
also known as asymmetric cryptography, solves the key exchange + problem by defining an algorithm which uses two keys, each of which + may be used to encrypt a message. If one key is used to encrypt a + message then the other must be used to decrypt it. This makes it + possible to receive secure messages by simply publishing one key + (the public key) and keeping the other secret (the private key).
+
+ +

Anyone can encrypt a message using the public key, but only the + owner of the private key will be able to read it. In this way, Alice + can send private messages to the owner of a key-pair (the bank), by + encrypting them using their public key. Only the bank will be able to + decrypt them.

+ + +

Message Digests

+ +

Although Alice may encrypt her message to make it private, there + is still a concern that someone might modify her original message or + substitute it with a different one, in order to transfer the money + to themselves, for instance. One way of guaranteeing the integrity + of Alice's message is for her to create a concise summary of her + message and send this to the bank as well. Upon receipt of the message, + the bank creates its own summary and compares it with the one Alice + sent. If the summaries are the same then the message has been received + intact.

+ +

A summary such as this is called a message digest, one-way + function or hash function. Message digests are used to create + a short, fixed-length representation of a longer, variable-length message. + Digest algorithms are designed to produce a unique digest for each + message. Message digests are designed to make it impractically difficult + to determine the message from the digest and (in theory) impossible to + find two different messages which create the same digest -- thus + eliminating the possibility of substituting one message for another while + maintaining the same digest.

+ +

Another challenge that Alice faces is finding a way to send the digest + to the bank securely; if the digest is not sent securely, its integrity may + be compromised and with it the possibility for the bank to determine the + integrity of the original message. Only if the digest is sent securely can + the integrity of the associated message be determined.

+ +

One way to send the digest securely is to include it in a digital + signature.

+ + +

Digital Signatures

+

When Alice sends a message to the bank, the bank needs to ensure that the +message is really from her, so an intruder cannot request a transaction +involving her account. A digital signature, created by Alice and +included with the message, serves this purpose.

+ +

Digital signatures are created by encrypting a digest of the message and +other information (such as a sequence number) with the sender's private key. +Though anyone can decrypt the signature using the public key, only the +sender knows the private key. This means that only the sender can have signed +the message. Including the digest in the signature means the signature is only +good for that message; it also ensures the integrity of the message since no one +can change the digest and still sign it.

+

To guard against interception and reuse of the signature by an intruder at a +later date, the signature contains a unique sequence number. This protects +the bank from a fraudulent claim from Alice that she did not send the message +-- only she could have signed it (non-repudiation).

+ +
top
+
+

Certificates

+ +

Although Alice could have sent a private message to the bank, signed +it and ensured the integrity of the message, she still needs to be sure +that she is really communicating with the bank. This means that she needs +to be sure that the public key she is using is part of the bank's key-pair, +and not an intruder's. Similarly, the bank needs to verify that the message +signature really was signed by the private key that belongs to Alice.

+ +

If each party has a certificate which validates the other's identity, +confirms the public key and is signed by a trusted agency, then both +can be assured that they are communicating with whom they think they are. +Such a trusted agency is called a Certificate Authority and +certificates are used for authentication.

+ +

Certificate Contents

+ +

A certificate associates a public key with the real identity of + an individual, server, or other entity, known as the subject. As + shown in Table 1, information about the subject + includes identifying information (the distinguished name) and the + public key. It also includes the identification and signature of the + Certificate Authority that issued the certificate and the period of + time during which the certificate is valid. It may have additional + information (or extensions) as well as administrative information + for the Certificate Authority's use, such as a serial number.

+ +

Table 1: Certificate Information

+ + + + + + + + + + + + + +
SubjectDistinguished Name, Public Key
IssuerDistinguished Name, Signature
Period of ValidityNot Before Date, Not After Date
Administrative InformationVersion, Serial Number
Extended InformationBasic Constraints, Netscape Flags, etc.
+ + +

A distinguished name is used to provide an identity in a specific + context -- for instance, an individual might have a personal + certificate as well as one for their identity as an employee. + Distinguished names are defined by the X.509 standard [X509], which defines the fields, field names and + abbreviations used to refer to the fields (see Table + 2).

+ +

Table 2: Distinguished Name Information

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DN FieldAbbrev.DescriptionExample
Common NameCNName being certifiedCN=Joe Average
Organization or CompanyOName is associated with this
organization		O=Snake Oil, Ltd.
Organizational UnitOUName is associated with this
organization unit, such + as a department		OU=Research Institute
City/LocalityLName is located in this CityL=Snake City
State/ProvinceSTName is located in this State/ProvinceST=Desert
CountryCName is located in this Country (ISO code)C=XZ
+ + +

A Certificate Authority may define a policy specifying which + distinguished field names are optional and which are required. It + may also place requirements upon the field contents, as may users of + certificates. For example, a Netscape browser requires that the + Common Name for a certificate representing a server matches a wildcard + pattern for the domain name of that server, such + as *.snakeoil.com.

+ +

The binary format of a certificate is defined using the ASN.1 + notation [ASN1] [PKCS]. This + notation defines how to specify the contents and encoding rules + define how this information is translated into binary form. The binary + encoding of the certificate is defined using Distinguished Encoding + Rules (DER), which are based on the more general Basic Encoding Rules + (BER). For those transmissions which cannot handle binary, the binary + form may be translated into an ASCII form by using Base64 encoding + [MIME]. When placed between begin and end delimiter + lines (as below), this encoded version is called a PEM ("Privacy Enhanced + Mail") encoded certificate.

+ +

Example of a PEM-encoded certificate (snakeoil.crt)

-----BEGIN CERTIFICATE-----
+MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
+FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
+A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
+cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
+bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
+MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
+a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
+cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
+AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
+gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
+vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
+lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
+HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
+gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
+2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
+dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
+-----END CERTIFICATE-----
+ + +

Certificate Authorities

+ +

By verifying the information in a certificate request + before granting the certificate, the Certificate Authority assures + itself of the identity of the private key owner of a key-pair. + For instance, if Alice requests a personal certificate, the + Certificate Authority must first make sure that Alice really is the + person the certificate request claims she is.

+ +

Certificate Chains

+ +

A Certificate Authority may also issue a certificate for + another Certificate Authority. When examining a certificate, + Alice may need to examine the certificate of the issuer, for each + parent Certificate Authority, until reaching one which she has + confidence in. She may decide to trust only certificates with a + limited chain of issuers, to reduce her risk of a "bad" certificate + in the chain.

+ + +

Creating a Root-Level CA

+ +

As noted earlier, each certificate requires an issuer to assert + the validity of the identity of the certificate subject, up to + the top-level Certificate Authority (CA). This presents a problem: + who can vouch for the certificate of the top-level + authority, which has no issuer? In this unique case, the + certificate is "self-signed", so the issuer of the certificate is + the same as the subject. Browsers are preconfigured to trust well-known + certificate authorities, but it is important to exercise extra care in + trusting a self-signed certificate. The wide publication of a + public key by the root authority reduces the risk in trusting this + key -- it would be obvious if someone else publicized a key + claiming to be the authority.

+ +

A number of companies, such as Thawte and VeriSign + have established themselves as Certificate Authorities. These + companies provide the following services:

+ +
    +
  • Verifying certificate requests
    • +
  • Processing certificate requests
    • +
  • Issuing and managing certificates
    • +
+ +

It is also possible to create your own Certificate Authority. + Although risky in the Internet environment, it may be useful + within an Intranet where the organization can easily verify the + identities of individuals and servers.

+ + +

Certificate Management

+ +

Establishing a Certificate Authority is a responsibility which + requires a solid administrative, technical and management + framework. Certificate Authorities not only issue certificates, + they also manage them -- that is, they determine for how long + certificates remain valid, they renew them and keep lists of + certificates that were issued in the past but are no longer valid + (Certificate Revocation Lists, or CRLs).

+ +

For example, if Alice is entitled to a certificate as an + employee of a company but has now left + that company, her certificate may need to be revoked. + Because certificates are only issued after the subject's identity has + been verified and can then be passed around to all those with whom + the subject may communicate, it is impossible to tell from the + certificate alone that it has been revoked. + Therefore when examining certificates for validity + it is necessary to contact the issuing Certificate Authority to + check CRLs -- this is usually not an automated part of the process.

+ +

Note

+

If you use a Certificate Authority that browsers are not configured + to trust by default, it is necessary to load the Certificate + Authority certificate into the browser, enabling the browser to + validate server certificates signed by that Certificate Authority. + Doing so may be dangerous, since once loaded, the browser will + accept all certificates signed by that Certificate Authority.

+
+ + + +
top
+
+

Secure Sockets Layer (SSL)

+ +

The Secure Sockets Layer protocol is a protocol layer which may be +placed between a reliable connection-oriented network layer protocol +(e.g. TCP/IP) and the application protocol layer (e.g. HTTP). SSL provides +for secure communication between client and server by allowing mutual +authentication, the use of digital signatures for integrity and encryption +for privacy.

+ +

The protocol is designed to support a range of choices for specific +algorithms used for cryptography, digests and signatures. This allows +algorithm selection for specific servers to be made based on legal, export +or other concerns and also enables the protocol to take advantage of new +algorithms. Choices are negotiated between client and server when +establishing a protocol session.

+ +

Table 4: Versions of the SSL protocol

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionSourceDescription
SSL v2.0Vendor Standard (from Netscape Corp.)First SSL protocol for which implementations exist
SSL v3.0Expired Internet Draft (from Netscape Corp.) [SSL3]Revisions to prevent specific security attacks, add non-RSA + ciphers and support for certificate chains
TLS v1.0Proposed Internet Standard (from IETF) [TLS1]Revision of SSL 3.0 to update the MAC layer to HMAC, add block + padding for block ciphers, message order standardization and more + alert messages.
TLS v1.1Proposed Internet Standard (from IETF) [TLS11]Update of TLS 1.0 to add protection against Cipher block chaining + (CBC) attacks.
TLS v1.2Proposed Internet Standard (from IETF) [TLS12]Update of TLS 1.1 deprecating MD5 as hash, and adding incompatibility + to SSL so it will never negotiate the use of SSLv2.
+ + +

There are a number of versions of the SSL protocol, as shown in +Table 4. As noted there, one of the benefits in +SSL 3.0 is that it adds support of certificate chain loading. This feature +allows a server to pass a server certificate along with issuer certificates +to the browser. Chain loading also permits the browser to validate the +server certificate, even if Certificate Authority certificates are not +installed for the intermediate issuers, since they are included in the +certificate chain. SSL 3.0 is the basis for the Transport Layer Security +[TLS] protocol standard, currently in development by +the Internet Engineering Task Force (IETF).

+ +

Establishing a Session

+ +

The SSL session is established by following a handshake sequence + between client and server, as shown in Figure 1. This sequence may vary, depending on whether the server + is configured to provide a server certificate or request a client + certificate. Although cases exist where additional handshake steps + are required for management of cipher information, this article + summarizes one common scenario. See the SSL specification for the full + range of possibilities.

+ +

Note

+

Once an SSL session has been established, it may be reused. This + avoids the performance penalty of repeating the many steps needed + to start a session. To do this, the server assigns each SSL session a + unique session identifier which is cached in the server and which the + client can use in future connections to reduce the handshake time + (until the session identifier expires from the cache of the server).

+
+ +

+
+ Figure 1: Simplified SSL + Handshake Sequence

+ +

The elements of the handshake sequence, as used by the client and + server, are listed below:

+ +
    +
  1. Negotiate the Cipher Suite to be used during data transfer
    2. +
  2. Establish and share a session key between client and server
    3. +
  3. Optionally authenticate the server to the client
    4. +
  4. Optionally authenticate the client to the server
    5. +
+ +

The first step, Cipher Suite Negotiation, allows the client and + server to choose a Cipher Suite supported by both of them. The SSL3.0 + protocol specification defines 31 Cipher Suites. A Cipher Suite is + defined by the following components:

+ +
    +
  • Key Exchange Method
    • +
  • Cipher for Data Transfer
    • +
  • Message Digest for creating the Message Authentication Code (MAC)
    • +
+ +

These three elements are described in the sections that follow.

+ + +

Key Exchange Method

+ +

The key exchange method defines how the shared secret symmetric + cryptography key used for application data transfer will be agreed + upon by client and server. SSL 2.0 uses RSA key exchange only, while + SSL 3.0 supports a choice of key exchange algorithms including + RSA key exchange (when certificates are used), and Diffie-Hellman key + exchange (for exchanging keys without certificates, or without prior + communication between client and server).

+ +

One variable in the choice of key exchange methods is digital + signatures -- whether or not to use them, and if so, what kind of + signatures to use. Signing with a private key provides protection + against a man-in-the-middle-attack during the information exchange + used to generating the shared key [AC96, p516].

+ + +

Cipher for Data Transfer

+ +

SSL uses conventional symmetric cryptography, as described earlier, + for encrypting messages in a session. + There are nine choices of how to encrypt, including the option not to + encrypt:

+ +
    +
  • No encryption
    • +
  • Stream Ciphers +
      +
    • RC4 with 40-bit keys
      • +
    • RC4 with 128-bit keys
      • +
    • +
  • CBC Block Ciphers +
    • RC2 with 40 bit key
      • +
    • DES with 40 bit key
      • +
    • DES with 56 bit key
      • +
    • Triple-DES with 168 bit key
      • +
    • Idea (128 bit key)
      • +
    • Fortezza (96 bit key)
      • +
    • +
+ +

"CBC" refers to Cipher Block Chaining, which means that a + portion of the previously encrypted cipher text is used in the + encryption of the current block. "DES" refers to the Data Encryption + Standard [AC96, ch12], which has a number of + variants (including DES40 and 3DES_EDE). "Idea" is currently one of + the best and cryptographically strongest algorithms available, + and "RC2" is a proprietary algorithm from RSA DSI [AC96, ch13].

+ + +

Digest Function

+ +

The choice of digest function determines how a digest is created + from a record unit. SSL supports the following:

+ +
    +
  • No digest (Null choice)
    • +
  • MD5, a 128-bit hash
    • +
  • Secure Hash Algorithm (SHA-1), a 160-bit hash
    • +
+ +

The message digest is used to create a Message Authentication Code + (MAC) which is encrypted with the message to verify integrity and to + protect against replay attacks.

+ + +

Handshake Sequence Protocol

+ +

The handshake sequence uses three protocols:

+ +
    +
  • The SSL Handshake Protocol + for performing the client and server SSL session establishment.
    • +
  • The SSL Change Cipher Spec Protocol for actually + establishing agreement on the Cipher Suite for the session.
    • +
  • The SSL Alert Protocol for conveying SSL error + messages between client and server.
    • +
+ +

These protocols, as well as application protocol data, are + encapsulated in the SSL Record Protocol, as shown in + Figure 2. An encapsulated protocol is + transferred as data by the lower layer protocol, which does not + examine the data. The encapsulated protocol has no knowledge of the + underlying protocol.

+ +

+
+ Figure 2: SSL Protocol Stack +

+ +

The encapsulation of SSL control protocols by the record protocol + means that if an active session is renegotiated the control protocols + will be transmitted securely. If there was no previous session, + the Null cipher suite is used, which means there will be no encryption and + messages will have no integrity digests, until the session has been + established.

+ + +

Data Transfer

+ +

The SSL Record Protocol, shown in Figure 3, + is used to transfer application and SSL Control data between the + client and server, where necessary fragmenting this data into smaller units, + or combining multiple higher level protocol data messages into single + units. It may compress, attach digest signatures, and encrypt these + units before transmitting them using the underlying reliable transport + protocol (Note: currently, no major SSL implementations include support + for compression).

+ +

+
+ Figure 3: SSL Record Protocol +

+ + +

Securing HTTP Communication

+ +

One common use of SSL is to secure Web HTTP communication between + a browser and a webserver. This does not preclude the use of + non-secured HTTP - the secure version (called HTTPS) is the same as + plain HTTP over SSL, but uses the URL scheme https + rather than http, and a different server port (by default, + port 443). This functionality is a large part of what mod_ssl provides for the Apache webserver.

+ +
top
+
+

References

+ +
+
[AC96]
+
Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, +1996. See http://www.counterpane.com/ for various other materials by Bruce +Schneier.
+ +
[ASN1]
+
ITU-T Recommendation X.208, Specification of Abstract Syntax Notation +One (ASN.1), last updated 2008. See http://www.itu.int/ITU-T/asn1/. +
+ +
[X509]
+
ITU-T Recommendation X.509, The Directory - Authentication +Framework. For references, see http://en.wikipedia.org/wiki/X.509. +
+ +
[PKCS]
+
Public Key Cryptography Standards (PKCS), +RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.
+ +
[MIME]
+
N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions +(MIME) Part One: Format of Internet Message Bodies, RFC2045. +See for instance http://tools.ietf.org/html/rfc2045.
+ +
[SSL3]
+
Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol +Version 3.0, 1996. See http://www.netscape.com/eng/ssl3/draft302.txt.
+ +
[TLS1]
+
Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, +1999. See http://ietf.org/rfc/rfc2246.txt.
+ +
[TLS11]
+
The TLS Protocol Version 1.1, +2006. See http://tools.ietf.org/html/rfc4346.
+ +
[TLS12]
+
The TLS Protocol Version 1.2, +2008. See http://tools.ietf.org/html/rfc5246.
+
+
+
+

Available Languages:  en  | + fr  | + ja 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/ssl/ssl_intro.html.fr.utf8 b/docs/manual/ssl/ssl_intro.html.fr.utf8 new file mode 100644 index 0000000..420a1b1 --- /dev/null +++ b/docs/manual/ssl/ssl_intro.html.fr.utf8 @@ -0,0 +1,727 @@ + + + + + +Chiffrement SSL/TLS fort : Introduction - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Chiffrement SSL/TLS fort : Introduction

+
+

Langues Disponibles:  en  | + fr  | + ja 

+
+ + +

Ce chapitre en guise d'introduction est destiné aux lecteurs pour lesquels +le Web, HTTP et Apache sont familiers, mais ne sont pas des experts en matière +de sécurité. Il n'a pas la prétention d'être un guide détaillé sur le +protocole SSL, il ne traitera pas non plus des techniques spécifiques de gestion +des certificats dans une organisation, ni des importants problèmes légaux de +brevets ou des restrictions d'importation ou d'exportation. Il se veut plutôt +une base de travail pour les utilisateurs de mod_ssl en +rassemblant différents concepts, définitions et exemples comme point de départ +pour une exploration plus détaillée.

+ +
+ +
top
+
+

Techniques de chiffrement

+ +

La maîtrise de SSL nécessite la compréhension des algorithmes de +chiffrement, des fonctions relatives aux empreintes de messages (comme les +fonctions de type hash ou non réversibles), et des signatures numériques. Ces +techniques pourraient faire l'objet d'un ouvrage à elles seules (voir par +exemple [AC96]) et constituent les bases de la +confidentialité, de l'intégrité et de l'authentification.

+ +

Algorithmes de chiffrement

+ +

Supposons qu'Alice veuille envoyer un message à sa banque pour + transférer une certaine somme. Alice souhaiterait que le message soit + privé, car il contient des informations comme son numéro de compte et le + montant du transfert. Une solution consisterait à utiliser un algorithme de + chiffrement, technique qui permet de remplacer un message par sa version + chiffrée, illisible jusqu'à ce qu'elle soit déchiffrée. + Sous sa forme chiffrée, + le message ne peut être déchiffré qu'en utilisant une clé secrète. Sans la + clé, le message est inutilisable : les bons algorithmes de chiffrement + rendent si difficile la restitution du texte original par des intrus que + ceux-ci y gaspilleraient leurs efforts.

+ +

Il existe deux catégories d'algorithmes de chiffrement : conventionnel + ou à clé publique.

+ +
+
Chiffrement conventionnel
+
aussi connu sous le nom de chiffrement symétrique, il nécessite le + partage d'une clé entre l'expéditeur et le destinataire : une portion + d'information secrète permettant de chiffrer et déchiffrer un message. + Tant que cette clé reste secrète, personne à part l'expéditeur et le + destinataire ne peut lire le message. Si Alice et sa banque partagent une + clé secrète, ils peuvent donc s'envoyer l'un à l'autre des messages privés. + Le fait de partager une clé entre l'expéditeur et le destinataire avant + de communiquer, tout en la maintenant secrète vis à vis des autres, peut + toutefois poser des problèmes.
+ +
Chiffrement à clé publique
+
aussi connu sous le nom de chiffrement asymétrique, il résoud le + problème d'échange de clé en définissant un algorithme qui utilise deux + clés, chacune d'entre elles pouvant être utilisée pour chiffrer un message. + Si une des clés a été utilisée pour chiffrer le message, on doit utiliser + l'autre clé pour le déchiffrer. Il est ainsi possible de recevoir des + messages sécurisés simplement en rendant publique une des clés (la clé + publique), et en gardant l'autre clé secrète (la clé privée).
+
+ +

Tout le monde peut chiffrer un message en utilisant la clé publique, + mais seul le propriétaire de la clé privée sera en mesure de le lire. De + cette façon, Alice peut envoyer des messages privés au propriétaire d'une + paire de clés (sa banque), en les chiffrant à l'aide de la clé publique. + Seule la banque sera en mesure de les déchiffrer.

+ + +

Empreinte d'un message

+ +

Bien qu'Alice puisse chiffrer son message pour le rendre privé, il + subsiste toujours le risque que quelqu'un puisse modifier le message + original ou le remplacer par un autre, afin d'effectuer le transfert de + fonds à son profit, par exemple. Une solution pour garantir l'intégrité du + message consisterait pour Alice à créer un résumé concentré de son message + qu'elle enverrait à sa banque avec ce dernier. A la réception du message, + la banque crée son propre résumé et le compare avec celui qu'Alice a + envoyé. Si les deux résumés sont identiques, le message reçu n'a pas + été modifié.

+ +

Un résumé tel que celui-ci est appelé + empreinte numérique de message (message digest), + fonction irréversible (one-way function) ou + fonction de hashage (hash function). Une empreinte de message + constitue une représentation courte et de longueur fixe, d'un message plus + long et de longueur variable. Les algorithmes de création d'empreintes sont + conçus pour produire une empreinte unique pour chaque message. Les + empreintes de messages sont conçues pour que la restitution du message + à partir de l'empreinte soit d'une difficulté insurmontable, et qu'il soit + (en théorie) impossible de trouver deux messages différents qui produisent + la même empreinte -- ce qui élimine la possibilité de remplacer un message + par un autre en conservant la même empreinte.

+ +

Trouver le moyen d'envoyer l'empreinte de manière sécurisée à la banque + constitue un autre défit auquel Alice doit faire face ; si l'empreinte + n'est pas envoyée de manière sécurisée, son intégrité peut être compromise, + et avec elle, la possibilité pour la banque de vérifier l'intégrité du + message original. L'intégrité du message ne peut être vérifiée que si + l'empreinte qui lui est associée est envoyée de manière sécurisée.

+ +

Une solution pour envoyer l'empreinte de manière sécurisée consiste à + l'inclure dans une signature numérique.

+ + +

Signatures numériques

+

Quand Alice envoie un message à sa banque, cette dernière doit s'assurer +que le message a bien été envoyé par elle, pour éviter qu'un intrus puisse +effectuer une transaction sur son compte. Une signature numérique, +créée par Alice et incluse dans le message, permet d'atteindre cet +objectif.

+ +

Les signatures numériques peuvent être créées en chiffrant une empreinte de +message, ainsi que d'autres informations (comme un numéro d'ordre) avec la clé +privée de l'expéditeur. Bien que tout le monde puisse déchiffrer la +signature à l'aide de la clé publique, seul l'expéditeur connait la clé privée. +Ce qui implique que seul l'expéditeur peut avoir signé le message. Inclure +l'empreinte dans la signature entraîne que cette dernière n'est valable que +pour ce message ; ceci assure aussi l'intégrité du message car personne ne +peut modifier l'empreinte et ensuite signer le message.

+

Afin de se prémunir contre l'interception et la réutilisation de la +signature par un intrus quelques jours plus tard, la signature contient un +numéro d'ordre unique. Ceci protège la banque contre une plainte frauduleuse +de la part d'Alice alléguant qu'elle n'a pas envoyé le message -- +elle seule peut l'avoir signé (non-répudiation).

+ + +
top
+
+

Certificats

+ +

Bien qu'Alice soit parvenue à envoyer un message privé à sa banque, après +l'avoir signé et avoir ainsi assuré l'intégrité du message, elle doit encore vérifier +qu'elle communique réellement avec la banque. C'est à dire qu'elle doit +s'assurer que la clé publique qu'elle utilise appartient bien à la paire de +clés de la banque, et non à celle d'un intrus. +De même, la banque doit vérifier que la +signature du message a bien été construite avec la clé privée d'Alice.

+ +

Si chaque partie possède un certificat qui valide l'identité de l'autre, +confirme la clé publique, et est signé par un organisme de confiance, alors +les deux protagonistes peuvent être sûrs que la personne avec laquelle ils +communiquent est bien celle avec laquelle ils désirent le faire. Un tel +organisme de confiance s'appelle une Autorité de Certification, et +on utilise les certificats à des fins d'authentification.

+ +

Contenu d'un certificat

+ +

Un certificat associe une clé publique avec l'identité réelle d'un + individu, d'un serveur, ou d'une autre entité plus connue sous le nom de + sujet. Comme on le voit dans le Tableau 1, les + information concernant le sujet comprennent des informations + d'identification (le nom distinctif ou distinguished name - dn), ainsi que + la clé publique. Il comporte aussi l'identification et la signature de + l'autorité de certification qui a délivré le certificat, ainsi que la + période de validité de ce dernier. Il peut aussi contenir des informations + supplémentaires (ou extensions) telles que des informations de gestion + destinées à l'autorité de certification, comme un numéro de série.

+ +

Tableau 1: Information contenues dans un certificat

+ + + + + + + + + + + + + +
SujetNom distinctif, Clé publique
FournisseurNom distinctif, Signature
Période de validitéPas avant, Pas après
Informations de gestionVersion, Numéro de série
ExtensionsContraintes de base, Drapeaux Netscape, etc.
+ + +

Un nom distinctif sert à fournir une identité dans un contexte + spécifique -- par exemple, un individu peut posséder un certificat + personnel, et aussi un certificat en tant qu'employé. Les noms distinctifs + doivent respecter le standard X509 [X509], qui définit + les champs, les noms de champs, et les abréviations utilisées pour faire + référence aux champs (voir Tableau 2).

+ +

Tableau 2: Informations contenues dans le nom distinctif

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Champ du DNAbrév.DescriptionExemple
Nom complet (Common Name)CNNom certifiéCN=Joe Average
Organisation or EntrepriseONom est associé à cette
organisation		O=Snake Oil, Ltd.
Unité organisationnelle (Organizational Unit)OUNom est associé avec cette
unité organisationnelle, + par exemple un département		OU=Research Institute
Ville/LocalisationLNom est localisé dans cette villeL=Snake City
Etat/ProvinceSTNom est localisé dans cet état/provinceST=Desert
PaysCNom est localisé dans ce pays (code ISO)C=XZ
+ + +

Une autorité de certification peut définir une contrainte spécifiant + quels champs du nom distinctif sont optionnels et lesquels sont + obligatoires. Elle peut aussi imposer des contraintes sur le contenu des + champs, ce que peuvent aussi faire les utilisateurs de certificats. Par + exemple, un navigateur Netscape peut exiger, dans le cas d'un certificat + de serveur, que le nom complet (Common Name) corresponde à un nom générique + contenant le nom de domaine du serveur, comme + *.snakeoil.com.

+ +

Le format binaire d'un certificat est défini en utilisant la + notation ASN.1 [ASN1] [PKCS]. + Cette notation definit la manière de spécifier les contenus, et les règles + d'encodage définissent la manière dont ces information sont converties au + format binaire. L'encodage binaire du certificat est défini par les Règles + d'Encodage Distinctives (Distinguished Encoding Rules - DER), qui se basent + d'une manière plus générale sur les Règles d'Encodage de Base (Basic + Encoding Rules - BER). Pour les transmissions qui ne supportent pas le + format binaire, ce dernier peut être converti au format ASCII en utilisant + le codage Base64 [MIME]. Lorsqu'il est placé entre des + délimiteurs de début et de fin (comme ci-dessous), on dit que le certificat + est encodé au format PEM ("Privacy Enhanced Mail").

+ +

Exemple de certificat encodé au format PEM (snakeoil.crt)

-----BEGIN CERTIFICATE-----
+MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
+FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
+A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
+cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
+bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
+MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
+a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
+cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
+AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
+gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
+vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
+lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
+HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
+gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
+2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
+dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
+-----END CERTIFICATE-----
+ + +

Autorités de certification

+ +

En vérifiant les informations contenues dans une demande de certificat + avant de l'accorder, l'autorité de certification s'assure de l'identité du + propriétaire de la clé privée issue de sa paire de clés. Par exemple, Si + Alice demande un certificat personnel, l'autorité de certification doit + d'abord s'assurer qu'elle correspond vraiment à la personne à laquelle + la demande de certificat fait référence.

+ +

Chaînes de certification

+ +

Une autorité de certification peut aussi émettre un certificat à + destination d'une + autre autorité de certification. Pour vérifier un certificat, Alice + peut être amenée à vérifier le certificat de l'émetteur pour chaque + autorité de certification parente, jusqu'à ce qu'elle en atteigne une + en qui elle a confiance. Elle peut aussi ne faire confiance qu'aux + certificats faisant l'objet d'une chaîne limitée d'émetteurs, afin + de réduire le risque de rencontrer un "mauvais" certificat dans la + chaîne.

+ + +

Création d'une autorité de certification racine

+ +

Comme indiqué plus haut, chaque certificat nécessite la validation + de l'identité du sujet par un émetteur de certificats + de niveau supérieur, et ceci en + remontant jusqu'à l'Autorité de Certification (CA) racine. Ceci pose un + problème : qui va se porter garant du certificat de l'autorité racine + qui ne possède pas d'émetteur de certificat ? C'est uniquement dans ce + cas que le certificat est auto-signé, l'émetteur du certificat et son + sujet étant confondus. Les navigateurs sont préconfigurés avec une + liste d'autorités de certification de confiance, mais il est important + d'être extrèmement prudent avant de faire confiance à un certificat + auto-signé. La large publication d'une clé publique par l'autorité + racine réduit cependant les risques encourus + en faisant confiance à cette clé -- + si quelqu'un publiait une clé en se faisant passer pour l'autorité, il + serait vite démasqué.

+ +

Quelques compagnies, comme Thawte et VeriSign, + se sont proclamées elles-mêmes Autorités de Certification. Ces + compagnies proposent les services suivant :

+ +
    +
  • Vérification des demandes de certificats
    • +
  • Traitement des demandes de certificats
    • +
  • Emission et gestion des certificats
    • +
+ +

Vous pouvez aussi créer votre propre autorité de certification. Bien + que risqué dans l'environnement de l'Internet, ceci peut s'avérer utile + dans un Intranet, où l'organisme peut vérifier facilement les identités + des individus et des serveurs.

+ + +

Gestion des certificats

+ +

Constituer une autorité de certification représente une + responsabilité qui nécessite une solide infrastructure administrative, + technique et gestionnaire. Les autorités de certification ne se + contentent pas d'émettre des certificats, elles doivent aussi les gérer + -- à savoir elles déterminent leur durée de validité, elles les + renouvellent, et elles maintiennent des listes de certificats qui ont + été émis dans le passé mais ne sont plus valides (Listes de révocations + de certificats, ou CRLs).

+ +

Par exemple, si Alice est titulaire d'un certificat en tant + qu'employée d'une compagnie, mais vient de quitter cette compagnie, + son certificat doit être révoqué. Comme les certificats ne sont émis + qu'après vérification de l'identité du sujet, et peuvent être envoyés + à tous ceux avec lesquels le sujet peut communiquer, il est impossible + de discerner à partir du seul certificat s'il a été révoqué. Pour + vérifier la validité d'un certificat, il est donc nécessaire de + contacter l'autorité de certification qui l'a émis afin de pouvoir + consulter ses listes de révocations de certificats -- ce qui n'est + en général pas une partie automatique du processus.

+ +

Note

+

Si votre autorité de certification ne fait pas partie de la liste + des autorités de confiance de votre navigateur, il faut enregistrer le + certificat de l'autorité de certification dans ce dernier, ce qui lui + permettra de valider les certificats de serveurs signés par cette + autorité de certification. Ceci peut être dangereux, car une fois le + certificat enregistré, le navigateur acceptera tous les certificats + signés par cette autorité de certification.

+
+ + + +
top
+
+

Couche Points d'Accès Sécurisés - Secure Sockets Layer (SSL)

+ +

Le protocole Couche Points d'Accès Sécurisés est une couche protocolaire +qui pourrait s'intercaler entre un protocole d'une couche réseau orientée +connexion (comme TCP/IP) et une couche protocolaire d'application (comme HTTP). +SSL fournit une communication sécurisée entre client et serveur en permettant +l'authentification mutuelle, l'utilisation des signatures numériques pour la +vérification de l'intégrité des données, et le chiffrement pour la +confidentialité.

+ +

Ce protocole est conçu pour supporter un grand choix d'algorithmes +spécifiques utilisés pour la cryptographie, les empreintes et les signatures. +Ceci permet la sélection d'un algorithme pour des serveurs spécifiques en +respectant la légalité, les règles d'exportation ou autres contraintes, et +permet aussi au protocole de tirer parti des nouveaux algorithmes. Ces choix +font l'objet d'une négociation entre client et serveur lors de +l'établissement de la session protocolaire.

+ +

Tableau 4: Versions du protocole SSL

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionSourceDescription
SSL v2.0Standard du fournisseur (de Netscape Corp.)Premier protocole SSL pour lequel il existe des implémentations
SSL v3.0Projet Internet arrivé à expiration (de Netscape Corp.) [SSL3]Comporte des révisions permettant de prévenir certaines attaques de + sécurité spécifiques, ajout de chiffrements non RSA, et support des + chaînes de certification
TLS v1.0Standard proposé pour l'Internet (de l'IETF) [TLS1]Révision de SSL 3.0 pour mettre à jour la couche MAC vers HMAC, + ajout du bourrage de bloc pour le chiffrement de bloc, standardisation + de l'ordonnancement des messages et plus de messages d'alerte.
TLS v1.1Standard proposé pour l'Internet (de l'IETF) [TLS11]Mise à jour de TLS 1.0 pour la protection contre les + attaques de type Cipher block chaining (CBC).
TLS v1.2Standard proposé pour l'Internet (de l'IETF) [TLS12]Mise à jour de TLS 1.1 rendant les condensés MD5 obsolètes, + et introduisant une incompatibilité avec SSL ce qui interdit toute + négociation en vue d'une utilisation de SSLv2.
+ + +

Il existe plusieurs versions du protocole SSL, comme le montre le +Tableau 4. Comme indiqué dans ce dernier, un des apports +de SSL 3.0 est le support du chargement des chaînes de certification. Cette +fonctionnalité permet à un serveur de passer au navigateur un certificat de +serveur accompagné du certificat de l'émetteur. Le chargement de la +chaîne permet aussi au navigateur de valider le certificat du serveur, même si +les certificats de l'autorité de certification ne sont pas installés pour les +émetteurs intermédiaires, car ils sont inclus dans la chaîne de certification. +SSL 3.0 sert de base au standard du protocole Sécurité de la Couche Transport +ou Transport Layer Security +[TLS], actuellement en développement au sein de +l'Internet Engineering Task Force (IETF).

+ +

Etablissement d'une session

+ +

La session SSL est établie en suivant une séquence d'échanges + d'informations entre client et serveur, comme le montre la + Figure 1. Cette séquence peut varier, selon que + le serveur est configuré pour fournir un certificat de serveur ou + réclame un certificat client. Bien que dans certains cas, des étapes + d'échanges d'informations supplémentaires soient nécessaires pour la + gestion des informations de chiffrement, cet article résume un scénario + courant. Se reporter aux spécifications SSL pour avoir la liste de + toutes les possibilités.

+ +

Note

+

Une fois la session SSL établie, elle peut être réutilisée. Ceci + permet d'éviter la perte de performances due à la répétition des nombreuses + étapes nécessaires à l'établissement d'une session. Pour parvenir à ceci, + le serveur assigne un identifiant de session unique à chaque session SSL ; + cet identifiant est mis en cache dans le serveur et le client peut + l'utiliser pour des connexions ultérieures afin de réduire la durée des + échanges d'informations (et ceci jusqu'à ce que l'identifiant de session + arrive à expiration dans le cache du serveur).

+
+ +

+
+ Figure 1 : Séquence + simplifiée d'échanges d'informations SSL

+ +

Les éléments de la séquence d'échanges d'informations, tels qu'ils + sont utilisés par le client et le serveur, sont énumérés ci-après :

+ +
    +
  1. Négociation de la suite de chiffrement à utiliser durant le transfert des données
    2. +
  2. Elaboration et échange d'une clé de session entre le client et le serveur
    3. +
  3. Authentification éventuelle du serveur par le client
    4. +
  4. Authentification éventuelle du client par le serveur
    5. +
+ +

La première étape, la négociation de la suite de chiffrement, permet au + client et au serveur de choisir une suite de chiffrement qu'ils supportent + tous les deux. La spécification du protocole SSL 3.0 définit 31 suites de + chiffrement. Une suite de chiffrement se compose des éléments + suivants :

+ +
    +
  • Méthode d'échange de la clé
    • +
  • Chiffrement du transfert des données
    • +
  • Empreinte du message servant à créer le code d'authentification du + message (MAC)
    • +
+ +

Ces trois éléments sont décrits dans les sections suivantes.

+ + +

Méthode d'échange de la clé

+ +

La méthode d'échange de la clé définit la manière + dont la clé de chiffrement + symétrique secrète et partagée utilisée pour le transfert des données de + l'application sera acceptée par le client et le serveur. SSL 2.0 utilise + l'échange de clé RSA seulement, tandis que SSL 3.0 supporte tout un choix + d'algorithmes d'échange de clé incluant l'échange de clé RSA (quand les + certificats sont utilisés), et l'échange de clés Diffie-Hellman (pour + échanger des clés sans certificat, ou en l'absence de communication + préalable entre le client et le serveur).

+ +

Les signatures numériques constituent une variante dans le choix des + méthodes d'échange de clé -- utiliser les signatures ou pas, et dans + l'affirmative, quel genre de signatures utiliser. La signature à l'aide + d'une clé privée fournit une protection contre une attaque + "man-in-the-middle" au cours de laquelle + l'échange d'informations destiné à générer la + clé partagée peut être intercepté [AC96, p516].

+ + +

Chiffrement du transfert de données

+ +

Comme décrit plus haut, SSL utilise le chiffrement symétrique + conventionnel pour chiffrer les messages au cours d'une session. Il existe + neuf choix possibles pour le chiffrement, y compris l'option du transfert + non chiffré :

+ +
    +
  • Pas de chiffrement
    • +
  • Chiffrement en continu (Stream Ciphers) +
      +
    • RC4 avec clés de 40 bits
      • +
    • RC4 avec clés de 128 bits
      • +
    • +
  • Chiffrement par blocs CBC (CBC Block Ciphers) +
    • RC2 avec clé de 40 bits
      • +
    • DES avec clé de 40 bits
      • +
    • DES avec clé de 56 bits
      • +
    • Triple-DES avec clé de 168 bits
      • +
    • Idea (clé de 128 bits)
      • +
    • Fortezza (clé de 96 bits)
      • +
    • +
+ +

"CBC" signifie Cipher Block Chaining (Chaînage de blocs chiffrés), + c'est à dire qu'une portion du bloc de texte chiffré précédent est utilisée + pour le chiffrement du bloc courant. "DES" signifie Data Encryption + Standard (Standard de Chiffrement des Données) + [AC96, ch12], et possède de nombreuses variantes + (telles que DES40 et 3DES_EDE). Parmi les algorithmes disponibles, "Idea" + est actuellement un des meilleurs et des plus puissants sur le plan + cryptographique, et "RC2" est un algorithme propriétaire de RSA DSI + [AC96, ch13].

+ + +

Fonction de création d'empreinte

+ +

Le choix d'une fonction de création d'empreinte détermine la manière + dont une empreinte est créée à partir d'une unité de données. SSL supporte + les fonctions suivantes :

+ +
    +
  • Pas d'empreinte (choix Null)
    • +
  • MD5, une empreinte de 128 bits
    • +
  • Algorithme d'Empreinte Sécurisée (Secure Hash Algorithm - SHA-1), une + empreinte de 160 bits
    • +
+ +

On utilise l'empreinte de message pour créer un Code d'Authentification + de Message (Message Authentication Code - MAC) qui est chiffré avec le + message afin de vérifier son intégrité et de se protéger contre les + attaques de type "rejeu".

+ + +

Protocole de la séquence d'échanges d'informations

+ +

La séquence d'échanges d'informations utilise trois protocoles :

+ +
    +
  • Le Protocole d'échanges d'informations SSL pour établir + la session SSl entre le client et le serveur.
    • +
  • Le Protocole de spécification du chiffrement SSL pour + l'agrément effectif de la suite de chiffrement à utiliser + pour la session.
    • +
  • Le Protocole d'alertes SSL pour la transmission de + messages d'erreur SSL entre le client et le serveur.
    • +
+ +

Ces protocoles, ainsi que les données du protocole de l'application, + sont encapsulés dans le Protocole d'enregistrement SSL + (SSL Record Protocol), comme + le montre la Figure 2. Un protocole encapsulé est + tranféré en tant que données par le protocole de la couche de niveau + inférieur, qui ne se préoccupe pas du contenu des données. Le protocole + encapsulé n'a aucune connaissance du protocole sous-jacent.

+ +

+
+ Figure 2: + Pile du protocole SSL

+ +

L'encapsulation des protocoles de contrôle SSL dans le protocole + d'enregistrement signifie que si une session active est renégociée, les + protocoles de contrôle seront transmis de manière sécurisée. S'il n'y + avait pas de session préalable, la suite de chiffrement Null est utilisée, + ce qui signifie que les messages ne seront pas chiffrés et ne possèderont + pas d'empreinte d'intégrité, jusqu'à ce que la session ait été établie.

+ + +

Transmission des données

+ +

Le protocole d'enregistrement SSL, comme le montre la + Figure 3, est utilisé pour transmettre les données + de l'application et les données de contrôle SSL entre le client et le + serveur, les données étant nécessairement fragmentées en éléments plus + petits, ou plusieurs messages de données avec protocole de niveau + supérieur pouvant être combinés en un seul élément. Ce protocole peut + joindre des signatures d'empreintes, compresser et chiffrer ces éléments + avant de les transmettre en utilisant le protocole fiable de transport + sous-jacent (Note : actuellement, aucune implémentation majeure de SSL + n'inclut le support de la compression).

+ +

+
+ Figure 3: + Protocole d'enregistrement SSL

+ + +

Sécurisation des communications HTTP

+ +

Une des utilisations courantes de SSL est la sécurisation des + communication HTTP sur le Web entre un navigateur et un serveur web. Ceci + n'exclut pas l'utilisation de HTTP non sécurisé - la version sécurisée + (appelée HTTPS) est identique à du vrai HTTP sur SSL, + mais utilise le préfixe + d'URL https au lieu de http, et un port + de serveur différent (par défaut le port 443). + Ceci constitue pour une large part + ce qu'apporte mod_ssl au serveur web Apache.

+ +
top
+
+

Références

+ +
+
[AC96]
+
Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, +1996. Voir http://www.counterpane.com/ pour diverses autres productions de Bruce +Schneier.
+ +
[ASN1]
+
ITU-T Recommendation X.208, Specification of Abstract Syntax Notation +One (ASN.1), dernière mise à jour en 2008. Voir http://www.itu.int/ITU-T/asn1/. +
+ +
[X509]
+
ITU-T Recommendation X.509, The Directory - Authentication +Framework. A titre de référence, voir http://en.wikipedia.org/wiki/X.509. +
+ +
[PKCS]
+
Public Key Cryptography Standards (PKCS), +RSA Laboratories Technical Notes, Voir http://www.rsasecurity.com/rsalabs/pkcs/.
+ +
[MIME]
+
N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions +(MIME) Part One: Format of Internet Message Bodies, RFC2045. +Voir par exemple http://tools.ietf.org/html/rfc2045.
+ +
[SSL3]
+
Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol +Version 3.0, 1996. Voir http://www.netscape.com/eng/ssl3/draft302.txt.
+ +
[TLS1]
+
Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, +1999. Voir http://ietf.org/rfc/rfc2246.txt.
+ +
[TLS11]
+
Le protocole TLS Version 1.1, +2006. Voir http://tools.ietf.org/html/rfc4346.
+ +
[TLS12]
+
Le protocole TLS Version 1.2, +2008. Voir http://tools.ietf.org/html/rfc5246.
+
+
+
+

Langues Disponibles:  en  | + fr  | + ja 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/ssl/ssl_intro.html.ja.utf8 b/docs/manual/ssl/ssl_intro.html.ja.utf8 new file mode 100644 index 0000000..b48ad3f --- /dev/null +++ b/docs/manual/ssl/ssl_intro.html.ja.utf8 @@ -0,0 +1,730 @@ + + + + + +SSL/TLS 暗号化: はじめに - Apache HTTP サーバ バージョン 2.4 + + + + + + +
+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

+

Apache HTTP サーバ バージョン 2.4

+
+
<-
+

SSL/TLS 暗号化: はじめに

+
+

翻訳済み言語:  en  | + fr  | + ja 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+ +
+

標準規格の良い所は、たくさんの規格から選べるということだ。 +そして、もし本当にどの規格も気に入らなければ、 +一年待つだけで探していた規格が現れる。

+ +

-- A. Tanenbaum, "Introduction to +Computer Networks"

+
+ +

+入門ということで、この章は Web、HTTP、Apache に通じている +読者向けですが、セキュリティ専門家向けではありません。 +SSL プロトコルの決定的な手引きであるつもりはありません。 +また、組織内の認証管理のための特定のテクニックや、 +特許や輸出規制などの重要な法的な問題についても扱いません。 +むしろ、更なる研究への出発点として色々な概念、定義、例を並べることで +mod_ssl のユーザに基礎知識を提供する事を目的としています。

+ +

ここに示された内容は主に、原著者の許可の下 +The Open Group Research Institute の Frederick J. Hirsch + 氏の記事 +Introducing SSL and Certificates using SSLeay を基にしています。 +氏の記事は Web Security: A Matter of +Trust, World Wide Web Journal, Volume 2, Issue 3, Summer 1997 +に掲載されました。 +肯定的な意見は Frederick Hirsch 氏 + (元記事の著者) へ全ての苦情は Ralf S. Engelschall ( +mod_ssl の作者) へお願いします。 +(訳注: 訳については +Apache ドキュメント翻訳プロジェクト +へお願いします。)

+
+ +
top
+
+

暗号化技術

+ +

SSL を理解するには、暗号アルゴリズム、 +メッセージダイジェスト関数(別名: 一方向関数、ハッシュ関数)、 +電子署名などへの理解が必要です。 +これらの技術は本が丸ごと必要な題目で +(例えば [AC96] を参照)、 +プライバシー、信用、認証などの技術の基礎となっています。

+ +

暗号アルゴリズム

+ +

例えば、アリスが送金のために銀行にメッセージを送りたいとします。 + 口座番号や送金の金額が含まれるため、 + アリスはそのメッセージを秘密にしたいと思います。 + 解決方法の一つは暗号アルゴリズムを使って、メッセージを + 復号されるまで読むことができない暗号化された + 形態に変えてしまうことです。 + その形態になると、 + メッセージは秘密の鍵によってのみ復号化することができます。 + 鍵なしでは、メッセージは役に立ちません。 + 良い暗号アルゴリズムは、侵入者が元のテキストを解読することを + 非常に難しくするため、努力が割に合わなくさせます。

+ +

暗号アルゴリズムには + 従来型と公開鍵の二つの種類があります。

+ +
+
従来型暗号
+
対称暗号としても知られ、 + 送信者と受信者が鍵を共有することが必要です。 + 鍵とは、メッセージを暗号化したり復号するのに使われる秘密 + の情報のことです。 + この鍵が秘密になっている限り、送信者と受信者以外は誰もメッセージを読 + むことができません。 + もしも、アリスと銀行が秘密の鍵を知っているなら、 + 彼らはお互いに秘密のメッセージを送ることができるでしょう。 + ただし交信の前に、事前に内密に鍵を共有するという作業自体は難題かもしれません。
+ +
公開鍵暗号
+
非対称暗号としても知られ、 + メッセージを暗号化することのできる二つの鍵 + を使用するアルゴリズムを定義することで鍵のやり取りの問題を解決 + します。 + もし、ある鍵が暗号化に使われたなら、 + もう片方の鍵で復号しなければいけません。 + この方式によって、一つの鍵を公表して(公開鍵)、 + もう片方を秘密にしておく(秘密鍵)だけで、 + 安全なメッセージを受け取ることができます。
+
+ +

公開鍵を使って誰もがメッセージを暗号化できますが、秘 + 密鍵の持ち主だけがそれを読むことができます。 + この方法で、銀行の公開鍵を使って暗号化することで、 + アリスは秘密のメッセージを送ることができます。 + 銀行のみが送られたメッセージを復号することができます。

+ + +

メッセージダイジェスト

+ +

アリスはメッセージを秘密にすることができますが、 + 誰かが例えば自分に送金するようにメッセージを変更したり、 + 別のものに置き換えてしまうかもしれないという問題があります。 + アリスのメッセージだという信憑性を保証する方法の一つは、 + メッセージの簡潔なダイジェストを作って、それも銀行に送るというものです。 + メッセージを受け取ると銀行側でもダイジェストを作成し、 + アリスが送ったダイジェストと比べます。もし一致したなら、 + 受け取ったメッセージは無傷だということになります。

+ +

このような要約はメッセージダイジェスト、 + 一方行関数、またはハッシュ関数と呼ばれます。 + メッセージダイジェストは長い可変長のメッセージから + 短い固定長の表現を作るのに使われます。 + ダイジェストアルゴリズムはメッセージから + 一意なダイジェストを生成するように作られています。 + メッセージダイジェストはダイジェストから元のメッセージを + 判定するのがとても難しいようにできていて、 + 同じ要約を作成する二つのメッセージを探すのは(理論上)不可能です。 + これによって、要約を変更することなくメッセージを置き換えられる + 可能性を排除しています。

+ +

アリスへのもう一つの問題は、このダイジェストを安全に送る方法を探すことです。 + ダイジェストが安全に送られればダイジェストの信憑性が保障されて、 + ダイジェストの信憑性をもってオリジナルメッセージの信憑性を得ることができます。 + ダイジェストを安全に送った場合にのみ、そのメッセージの + 信憑性が得られます。

+ +

ダイジェスト安全に送る方法の一つは、電子署名に含める方法です。

+ + +

電子署名

+

アリスが銀行にメッセージを送ったとき、 +侵入者が彼女になりすまして彼女の口座への取引を申請できないように、 +銀行側ではメッセージが本当に彼女からのものか確実に分かるようにしなければなりません。 +アリスによって作成されて、メッセージに含まれた +電子署名がここで役に立ちます。

+ +

電子署名はメッセージのダイジェストやその他の情報(処理番号など)を +送信者の秘密鍵で暗号化することで作られます。 +誰もが公開鍵を使って署名を復号することができますが、 +送信者のみが秘密鍵を知っています。 +これは送信者のみが署名しえたことを意味します。 +ダイジェストを電子署名に含むことは、 +その署名がそのメッセージのみに有効であることを意味します。 +これは、誰もダイジェストを変えて署名をすることができないため、 +メッセージの信用も保証します。

+ +

侵入者が署名を傍受して後日に再利用するのを防ぐため +電子署名には一意な処理番号が含まれます。 +これは、アリスがそんなメッセージは送っていないと言う詐欺 +から銀行を守ります。 +彼女だけが署名しえたからです。(否認防止)

+ +
top
+
+

証明書

+ +

アリスは秘密のメッセージを銀行に送り、 +署名をして、メッセージの信用を保証することができるおうになりましたが、 +通信している相手が本当に銀行なのか確かめなくてはいけません。 +つまり彼女が使おうとしている公開鍵が、銀行の秘密鍵と対になっていて、 +侵入者の秘密鍵と対になっているわけではないことを +確かめなくてはいけないことを意味しています。 +同様に銀行は、メッセージの署名が本当にアリスの持っている +秘密鍵で署名された署名かを確認する必要があります。

+ +

もし両者に身元を証明し、公開鍵を確認し、また信頼された機関が署名 +した証明書があれば、両者とも通信相手について正しい相手だと +確信することができます。 +そのような信頼された機関は認証局 + (Certificate Authority または CA) と呼ばれ、 +証明書 (certificate) が認証 (authentication) に使われます。

+ +

証明書の内容

+ +

証明書は公開鍵と個人、サーバ、その他の主体の実在の身元を + 関連付けます。 + 表1に示されるように証明対象の情報は + 身元証明の情報(識別名)と公開鍵が含まれます。 + 証明書はまた、認証局の身元証明と署名、そして証明書の有効期間を + 含みます。 + シリアルナンバーなどの認証局の管理上の情報や + その他の追加の情報が含まれているかもしれません。

+ +

表1: 証明書情報

+ + + + + + + + + + + + + +
証明対象識別名、公開鍵
発行者識別名、公開鍵
有効期間開始日、失効日
管理情報バージョン、シリアルナンバー
拡張情報基本的な制約、ネットスケープフラッグ、その他
+ + +

識別名(ディスティングイッシュ・ネーム)は特定の状況における + 身分証明を提供するのに使われています。例えば、ある人は + 私用と会社とで別々の身分証明を持つかもしれません。 + + 識別名は X.509 標準規格 [X509] で定義されています。 + X.509 標準規格は、項目、項目名、そして項目の略称を定義しています。(表 + 2 参照)

+ +

表 2: 識別名情報

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
識別名項目略称説明例
Common Name (コモンネーム)CN認証される名前
+ SSL接続するURL		CN=www.example.com
Organization or Company (組織名)O団体の正式英語組織名O=Example Japan K.K.
Organizational Unit (部門名)OU部署名などOU=Customer Service
City/Locality (市区町村)L所在してる市区町村L=Sapporo
State/Province (都道府県)ST所在してる都道府県ST=Hokkaido
Country(国)C所在している国名の ISO コード
+ 日本の場合 JP + 		C=JP
+ + +

認証局はどの項目が省略可能でどれが必須かの方針を定義する + かもしれません。項目の内容についても認証局や証明書のユーザからの + 要件があるかもしれません。 + 例えばネットスケープのブラウザは、サーバの証明書の + Common Name (コモンネーム)がサーバのドメイン名の + *.snakeoil.com + というようなワイルドカードのパターンにマッチすること + を要求します。

+ +

バイナリ形式の証明書は ASN.1 表記法 + [X208] [PKCS] で + 定義されています。 + この表記法は内容をどのように記述するかを定義し、 + 符号化の規定がこの情報がどのようにバイナリ形式に変換されるかを + 定義します。 + 証明書のバイナリ符号化は Distinguished Encoding + Rules (DER) で定義され、それはより一般的な Basic Encoding Rules + (BER) に基づいています。 + バイナリ形式を扱うことのできない送信では、 + バイナリ形式は Base64 符号化 [MIME] で + ASCII 形式に変換されることがあります。 + 開始デリミタ行と終了デリミタ行で囲まれた、この形式のことを + PEM ("Privacy Enhanced Mail") 符号化された証明書と言います。

+ +

PEM 符号化された証明書の例 (example.crt)

-----BEGIN CERTIFICATE-----
+MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
+FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
+A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
+cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
+bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
+MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
+a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
+cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
+AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
+gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
+vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
+lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
+HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
+gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
+2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
+dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
+-----END CERTIFICATE-----
+ + +

認証局

+ +

証明書を承認する前に、証明書要求に記載されている情報を確認し、 + 認証局は鍵の所有者の身元を確認します。 + 例えば、アリスが個人証明書を申請したとすると、 + 認証局はアリスが証明書の申請が主張する通りの + 当の本人だということを確認しなくてはいけません。

+ +

証明書の連鎖

+ +

認証局は他の認証局への証明書を発行することができます。 + 未知の証明書を調べる時に、アリスはその証明書の発行者 + に自信が持てるまで、発行者の証明書を + その上位階層の認証局をたどって調べる必要があります。 + 「悪質な」証明書の危険性を減らすため、 + 彼女は限られた連鎖の発行者のみ信頼するように + 決めることもできます。

+ + +

最上位認証局の作成

+ +

前に述べたように、全ての証明書について、 + 最上位の認証局(CA)までそれぞれの発行者が + 対象の身元証明の有効性を明らかにする必要があります。 + 問題は、誰がその最上位の認証機関の証明書を保証するのか、 + ということです。 + このような場合に限り、証明書は「自己署名」されます。 + ブラウザには、とてもよく知られている認証局が初期登録されていますが、 + 自己署名された証明書を信用する際には + 細心の注意が必要です。 + 最上位認証局が公開鍵を広く公表することで、 + その鍵を信頼するリスクを低くすることができます。 + もし、他人がその認証局になりすました時に、それが露見しや + すいからです。

+ +

Thawte + や VeriSign + のような多くの会社が認証局として開設しました。 + このような会社は以下のサービスを提供します:

+ +
    +
  • 証明書申請の確認
    • +
  • 証明書申請の処理
    • +
  • 証明書の発行と管理
    • +
+ +

自分で認証局を作ることも可能です。 + インターネット環境では危険ですが、 + 個人やサーバの身元証明が簡単に行える組織の + イントラネット内では役に立つかもしれません。

+ + +

証明書管理

+ +

認証局の開設は徹底した管理、技術、運用の体制を必要とする + 責任のある仕事です。 + 認証局は証明書を発行するだけでなく、 + 管理もしなければなりません。 + 具体的には、証明書がいつまで有効であり続けるかを決定し、更新し、 + また過去発行されて失効した証明書のリスト + (Certificate Revocation Lists または CRL) + を管理しなければいけません。

+ +

例えばアリスが過去、会社の社員であることを証明する証明書を持っていたが、 + 現在は退職していた際、その証明書は失効されなければなりません。 + 証明書は次々と人に渡されていくものなので、 + 証明書そのものから、それが取り消されたか判断することは + 不可能です。 + よって、証明書の有効性を調べるときには、 + 認証局に連絡して CRL を照合する必要があります。 + 普通この過程は自動化されているものではありません。

+ +

注意

+

ブラウザに信用できる認証局としてデフォルトで登録されていない + 認証局を使おうとした場合、 + 認証局の証明書をブラウザに読み込んで、 + ブラウザがその認証局によって署名されたサーバの証明書を + 有効にする必要があります。 + 一度読み込まれると、その認証局によって署名された全ての + 証明書を受け入れるため、危険を伴います。

+
+ + + +
top
+
+

Secure Sockets Layer (SSL)

+ +

Secure Sockets Layer プロトコルは信頼性のあるコネクション型の +ネットワーク層のプロトコル(例えば、TCP/IP)と +アプリケーション層のプロトコル(例えば、HTTP) +の間に置くことができます。 +SSL は、相互認証によってサーバとクライアント間の安全な通信を、 +電子署名によってデータの完全性を、 +そして暗号化によってプライバシを提供します。

+ +

SSL プロトコルは暗号化、ダイジェスト、電子署名について、 +様々なアルゴリズムをサポートするようにできています。 +こうすることで、法や輸出の規制を考慮に入れて、サーバに合わせた +アルゴリズムを選ぶことができ、また、新しいアルゴリズムを +利用していくことも可能にしています。 +アルゴリズムの選択はプロトコルセッション開始時に +サーバとクライアント間で取り決められます。

+ +

表4: SSL プロトコルのバージョン

+ + + + + + + + + + + + + + + + + + + +
バージョン出典説明ブラウザのサポート
SSL v2.0Vendor Standard (Netscape Corp. より) [SSL2]実装が現存する初めての SSL プロトコル- NS Navigator 1.x/2.x
+ - MS IE 3.x
+ - Lynx/2.8+OpenSSL
SSL v3.0Expired Internet Draft (Netscape Corp. より) [SSL3]特定のセキュリティ攻撃を防ぐための改訂、 + 非RSA 暗号の追加、証明書階層構造のサポート- NS Navigator 2.x/3.x/4.x
+ - MS IE 3.x/4.x
+ - Lynx/2.8+OpenSSL
TLS v1.0Proposed Internet Standard (IETF より) [TLS1]MAC レイヤを HMAC へ更新、ブロック暗号の block + padding、メッセージ順序の標準化、警告文の充実などのため + SSL 3.0 を改訂。- Lynx/2.8+OpenSSL
+ + +

表4に示されるとおり、SSL プロトコルには +いくつものバージョンがあります。 +表にも書かれているように、SSL 3.0 の利点の一つは +証明書階層構造をサポートすることです。 +この機能によって、サーバは自分の証明書に加えて、 +発行者の証明書をブラウザに渡すことができます。 +証明書階層構造によって、 +ブラウザに発行者の証明書が直接登録されていなくても、 +階層の中に含まれていれば、 +ブラウザはサーバの証明書を有効化することができます。 +SSL 3.0 は現在 Internet Engineering Task Force (IETF) +によって開発されている Transport Layer Security +[TLS] プロトコル標準規格の基礎となっています。

+ +

セッションの確立

+ +

図1で示されるように、 + セッションの確立はクライアントとサーバ間の + ハンドシェークシークエンスによって行なわれます。 + サーバが証明書を提供するか、クライアントの証明書をリクエストするか + というサーバの設定により、このシークエンスは異なるものとなります。 + 暗号情報の管理のために、追加のハンドシェーク過程が必要になる + 場合もありますが、この記事では + よくあるシナリオを手短に説明します。 + 全ての可能性についは、SSL 仕様書を参照してください。

+ +

注意

+

一度 SSL セッションが確立すると、セッションを再利用することで、 + セッションを開始するための多くの過程を繰り返すという + パフォーマンスの損失を防ぎます。 + そのため、サーバは全てのセッションに一意なセッション識別名を + 割り当て、サーバにキャッシュし、クライアントは次回から + (識別名がサーバのキャッシュで期限切れになるまでは) + ハンドシェークなしで接続することができます。

+
+ +

+
+ 図1: SSL + ハンドシェークシークエンス概略

+ +

サーバとクライアントで使われる + ハンドシェークシークエンスの要素を以下に示します:

+ +
    +
  1. データ通信に使われる暗号スイートの取り決め
    2. +
  2. クライアントとサーバ間でのセッション鍵の確立と共有
    3. +
  3. オプションとして、クライアントに対するサーバの認証
    4. +
  4. オプションとして、サーバに対するクライアントの認証
    5. +
+ +

第一ステップの暗号スイート取り決めによって、 + サーバとクライアントはそれぞれにあった + 暗号スイートを選ぶことができます。 + SSL3.0 プロトコルの仕様書は 31 の暗号スイートを定義しています。 + 暗号スイートは以下のコンポーネントにより定義されています:

+ +
    +
  • 鍵の交換手段
    • +
  • データ通信の暗号術
    • +
  • Message Authentication Code (MAC) 作成のための + メッセージダイジェスト
    • +
+ +

これらの三つの要素は以下のセクションで説明されています。

+ + +

鍵の交換手段

+ +

鍵の交換手段はアプリケーションのデータ通信に使われ、 + 共有される対称暗号鍵をどのようにがクライアントとサーバで + 取り決めるかを定義します。 + SSL 2.0 は RSA 鍵交換しか使いませんが、 + SSL 3.0 は (証明書が使われるときの) RSA 鍵交換や、 + (証明書無しの場合やクライアントとサーバの事前の通信が無い場合の) + Diffie-Hellman 鍵交換 + など様々な鍵交換アルゴリズムをサポートします。

+ +

鍵の交換方法における一つの選択肢は電子署名です。 + 電子署名を使うかどうか、また、 + どの種類の署名を使うかという選択があります。 + 秘密鍵で署名することで共有鍵を保護し、情報交換する時の + マン・イン・ザ・ミドル攻撃を防ぐことができます。 + [AC96, p516]

+ + +

データ通信の暗号術

+ +

SSL はセッションのメッセージの暗号化に前述した + 対称暗号方式を用います。 + 暗号化しないという選択肢も含め九つの暗号方式の選択肢があります:

+ +
    +
  • 暗号化なし
    • +
  • ストリーム暗号 +
      +
    • 40-bit 鍵での RC4
      • +
    • 128-bit 鍵での RC4
      • +
    • +
  • CBC ブロック暗号 +
    • 40 bit 鍵での RC2
      • +
    • 40 bit 鍵での DES
      • +
    • 56 bit 鍵での DES
      • +
    • 168 bit 鍵での Triple-DES
      • +
    • Idea (128 bit 鍵)
      • +
    • Fortezza (96 bit 鍵)
      • +
    • +
+ +

CBC とは暗号ブロック連鎖 (Cipher Block Chaining) + の略で、一つ前の暗号化された暗号文の一部が + ブロックの暗号化に使われることを意味します。 + DES はデータ暗号化標準規格 (Data Encryption Standard) + [AC96, ch12] の略で、 + DES40 や 3DES_EDE を含むいくつもの種類があります。 + Idea は現在最高なものの一つで、暗号術的には現在ある中で + 最も強力なものです。 + RC2 は RSA DSI による独占的なアルゴリズムです。 + [AC96, + ch13]

+ + +

ダイジェスト関数

+ +

+ ダイジェスト関数の選択はレコードユニットからどのようにダイジェストが生成されるかを決定します。 + SSL は以下をサポートします:

+ +
    +
  • ダイジェストなし
    • +
  • MD5 (128-bit ハッシュ)
    • +
  • Secure Hash Algorithm (SHA-1) (160-bit ハッシュ)
    • +
+ +

メッセージダイジェストは Message Authentication Code (MAC) + の生成に使われ、メッセージと共に暗号化され、メッセージの信憑性を + 確認し、リプレイ攻撃を防ぎます。

+ + +

ハンドシェークシークエンスプロトコル

+ +

ハンドシェークシークエンスは三つのプロトコルを使います:

+ +
    +
  • SSL ハンドシェークプロトコルは + クライアントとサーバ間での SSL セッションの確立に使われます。
    • +
  • SSL 暗号仕様変更プロトコルは + セッションでの暗号スイートの取り決めに使われます。
    • +
  • SSL 警告プロトコルは + クライアントサーバ間で SSL エラーを伝達するのに使われます。
    • +
+ +

三つのプロトコルは、アプリケーションプロトコルデータとともに、 + 図2に示すとおり SSL レコードプロトコル + でカプセル化されます。 + カプセル化されたプロトコルはデータを検査しない + 下層のプロトコルによってデータとして伝達されます。 + カプセル化されたプロトコルは下層のプロトコルに関して一切関知しません。

+ +

+
+ 図2: SSL プロトコルスタック +

+ +

+ レコードプロトコルで SSL コントロールプロトコルがカプセル化されているということは、 + アクティブなセッション上で再ネゴシエーションされたときにも、 + コントロールプロトコルは安全であることを意味します。 + 既存のセッションが無い場合は、Null 暗号スイートが使われ、 + 暗号化は行なわれず、セッションが確立するまでは + ダイジェストも無い状態となります。

+ + +

データ通信

+ +

図3に示される SSL レコードプロトコル + はクライアントとサーバ間のアプリケーションや + SSL コントロールデータの通信に使われます。 + 必要に応じてこのデータはより小さいユニットに分けられたり、 + いくつかの高級プロトコルをまとめて一ユニットとして通信が + 行なわれることもあります。 + データを圧縮し、ダイジェスト署名を添付して、 + これらのユニットを暗号化したのち、ベースとなっている + 信頼性のあるトランスポートプロトコルを用いるかもしれません。 + (注意: 現在メジャーな SLL 実装で圧縮をサポートしているものはありません)

+ +

+
+ 図 3: SSL レコードプロトコル +

+ + +

HTTP 通信の安全化

+ +

よくある SSL の使い方はブラウザとウェブサーバ間の HTTP 通信 + の安全化です。 + これは、従来の安全ではない HTTP の使用を除外するものではありません。 + 安全化されたもの (HTTPS と呼ばれます) は、SSL 上での普通の HTTP で、 + URL スキームに http の代わりに https + を用い、サーバで別のポートを使うことです (デフォルトでは443)。 + これが主に mod_ssl が Apache + ウェブサーバに提供する機能です。

+ +
top
+
+

参考文献

+ +
+
[AC96]
+
Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, +1996. See http://www.counterpane.com/ for various other materials by Bruce +Schneier.
+ +
[X208]
+
ITU-T Recommendation X.208, Specification of Abstract Syntax Notation +One (ASN.1), 1988. See for instance http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I. +
+ +
[X509]
+
ITU-T Recommendation X.509, The Directory - Authentication +Framework. See for instance http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509. +
+ +
[PKCS]
+
Public Key Cryptography Standards (PKCS), +RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.
+ +
[MIME]
+
N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions +(MIME) Part One: Format of Internet Message Bodies, RFC2045. +See for instance http://ietf.org/rfc/rfc2045.txt.
+ +
[SSL2]
+
Kipp E.B. Hickman, The SSL Protocol, 1995. See http://www.netscape.com/eng/security/SSL_2.html.
+ +
[SSL3]
+
Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol +Version 3.0, 1996. See http://www.netscape.com/eng/ssl3/draft302.txt.
+ +
[TLS1]
+
Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, +1999. See http://ietf.org/rfc/rfc2246.txt.
+
+
+
+

翻訳済み言語:  en  | + fr  | + ja 

+
top

コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file -- cgit v1.2.3