Mercurial > hg > nginx-site

comparison xml/tr/docs/http/configuring_https_servers.xml @ 593:130fad6dc1b4

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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) &ldquo;<i>s</i>&rdquo; ile belirtilen konusu (subject), &ldquo;<i>i</i>&rdquo; 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) &ldquo;<i>s</i>&rdquo; ile belirtilen konusu (subject), &ldquo;<i>i</i>&rdquo; 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&rsquo;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&rsquo;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