Mercurial > hg > nginx-site
comparison xml/tr/docs/http/configuring_https_servers.xml @ 593:130fad6dc1b4
Replaced the uses of "url" element with "literal".
author | Ruslan Ermilov <ru@nginx.com> |
---|---|
date | Thu, 19 Jul 2012 05:17:45 +0000 |
parents | 9913f1d51c07 |
children |
comparison
equal
deleted
inserted
replaced
592:d40371689c1c | 593:130fad6dc1b4 |
---|---|
132 /OU=ValiCert Class 2 Policy Validation Authority | 132 /OU=ValiCert Class 2 Policy Validation Authority |
133 /CN=http://www.valicert.com//emailAddress=info@valicert.com | 133 /CN=http://www.valicert.com//emailAddress=info@valicert.com |
134 ... | 134 ... |
135 </programlisting> | 135 </programlisting> |
136 | 136 |
137 Bu örnekte <url>www.GoDaddy.com</url> sunucu sertifikasının (server certificate #0) “<i>s</i>” ile belirtilen konusu (subject), “<i>i</i>” ile gösterilen ve aynı zamanda kendisi de sonraki sertifikanın (certificate #1) konusu (subject) olan, sertifikayı veren/yayınlayan (issuer) tarafından imzalanır. Sonraki sertifika (certificate #1) ise bir sonraki sertifika (certificate #2) tarafından imzalanmıştır ve bu son sertifika <i>ValiCert, Inc.</i> tarafından imzalanmıştır. Bu firmanın sertifikası, tarayıcının kurulumuyla gelen sertifika veritabanında bulunur. | 137 Bu örnekte <literal>www.GoDaddy.com</literal> sunucu sertifikasının (server certificate #0) “<i>s</i>” ile belirtilen konusu (subject), “<i>i</i>” ile gösterilen ve aynı zamanda kendisi de sonraki sertifikanın (certificate #1) konusu (subject) olan, sertifikayı veren/yayınlayan (issuer) tarafından imzalanır. Sonraki sertifika (certificate #1) ise bir sonraki sertifika (certificate #2) tarafından imzalanmıştır ve bu son sertifika <i>ValiCert, Inc.</i> tarafından imzalanmıştır. Bu firmanın sertifikası, tarayıcının kurulumuyla gelen sertifika veritabanında bulunur. |
138 </para> | 138 </para> |
139 | 139 |
140 <para> | 140 <para> |
141 Eğer sertifika dizisi eklemediyseniz, yalnızca bir sunucu sertifikası görürsünüz (server certificate #0). | 141 Eğer sertifika dizisi eklemediyseniz, yalnızca bir sunucu sertifikası görürsünüz (server certificate #0). |
142 </para> | 142 </para> |
192 ssl_certificate www.example.org.crt; | 192 ssl_certificate www.example.org.crt; |
193 ... | 193 ... |
194 } | 194 } |
195 </programlisting> | 195 </programlisting> |
196 | 196 |
197 Bu yapılandırmada, bir tarayıcı talep edilen sunucuya bakmadan, varsayılan sunucunun sertifikasını alır, örneğin: <url>www.example.com</url>. Bu SSL protokolüne özgü bir durumdan kaynaklanır. SSL bağlantısı, tarayıcının HTTP talebi göndermesinden önce kurulur ve nginx talep edilen sunucunun adını bilmez. Bu nedenle yalnızca varsayılan sunucunun sertifikasını önerir. | 197 Bu yapılandırmada, bir tarayıcı talep edilen sunucuya bakmadan, varsayılan sunucunun sertifikasını alır, örneğin: <literal>www.example.com</literal>. Bu SSL protokolüne özgü bir durumdan kaynaklanır. SSL bağlantısı, tarayıcının HTTP talebi göndermesinden önce kurulur ve nginx talep edilen sunucunun adını bilmez. Bu nedenle yalnızca varsayılan sunucunun sertifikasını önerir. |
198 </para> | 198 </para> |
199 | 199 |
200 <para> | 200 <para> |
201 Bu problemi çözmenin en eski ve sağlam methodu HTTPS sunucularının her birine ayrı IP adresleri atamaktır: | 201 Bu problemi çözmenin en eski ve sağlam methodu HTTPS sunucularının her birine ayrı IP adresleri atamaktır: |
202 | 202 |
224 | 224 |
225 <section id="certificate_with_several_names" | 225 <section id="certificate_with_several_names" |
226 name="Birçok ad içeren SSL sertifikası"> | 226 name="Birçok ad içeren SSL sertifikası"> |
227 | 227 |
228 <para> | 228 <para> |
229 Bir tekil IP’yi birçok HTTPS sunucu arasında paylaştırmanın başka yolları da vardır, ancak bunların hepsi dezavantajlara sahiptir. Bunlardan biri, birçok ad içeren bir sertifikanın, SubjectAltName sertifika alanında kullanılmasıdır. Örneğin: <url>www.example.com</url> ve <url>www.example.org</url>. Ancak SubjectAltName alan uzunluğu sınırlandırılmıştır. | 229 Bir tekil IP’yi birçok HTTPS sunucu arasında paylaştırmanın başka yolları da vardır, ancak bunların hepsi dezavantajlara sahiptir. Bunlardan biri, birçok ad içeren bir sertifikanın, SubjectAltName sertifika alanında kullanılmasıdır. Örneğin: <literal>www.example.com</literal> ve <literal>www.example.org</literal>. Ancak SubjectAltName alan uzunluğu sınırlandırılmıştır. |
230 </para> | 230 </para> |
231 | 231 |
232 <para> | 232 <para> |
233 Diğer bir yol ise bir sertifikayı bir wildcard adı ile birlikte kullanmaktır. Örneğin: <url>*.example.org</url>. Bu sertifika <url>www.example.org</url> ile eşleşir ancak <url>example.org</url> ve <url>www.sub.example.org</url> ile eşleşmez. Bu iki method birlikte de kullanılabilir. Bir sertifika SubjectAltName alanı içerisinde gerçek ve wildcard adlarını içerebilir. Örneğin: <url>example.org</url> ve <url>*.example.org</url>. | 233 Diğer bir yol ise bir sertifikayı bir wildcard adı ile birlikte kullanmaktır. Örneğin: <literal>*.example.org</literal>. Bu sertifika <literal>www.example.org</literal> ile eşleşir ancak <literal>example.org</literal> ve <literal>www.sub.example.org</literal> ile eşleşmez. Bu iki method birlikte de kullanılabilir. Bir sertifika SubjectAltName alanı içerisinde gerçek ve wildcard adlarını içerebilir. Örneğin: <literal>example.org</literal> ve <literal>*.example.org</literal>. |
234 </para> | 234 </para> |
235 | 235 |
236 <para> | 236 <para> |
237 Tüm sunuculardaki tekil hafıza kopyalarını devralması için, birçok ad içeren bir sertifika dosyası ve onun özel anahtar dosyasını, yapılandırmanın <i>http</i> düzeyinde bulundurmak en iyisidir: | 237 Tüm sunuculardaki tekil hafıza kopyalarını devralması için, birçok ad içeren bir sertifika dosyası ve onun özel anahtar dosyasını, yapılandırmanın <i>http</i> düzeyinde bulundurmak en iyisidir: |
238 | 238 |