Go daddy secure certificate authority g2

Hacker’s ramblings

Fixing curl with Go Daddy Secure Certificate Authority G2 CA root

Tuesday, June 7. 2016

Curl is one weird piece of software. Every time I use it, I get chills. The reason for this is, that it almost works and when it doesn’t there isn’t a damn thing you can to to fix it. The entire design of that software is . I’m lost for words here. I’m looking for words that describe: cumbersome, shitty, unorthodox, non-functional, and so on.

Since the lib-version is used by a number of libraries and other software as a means to provide HTTP-protocol implementation I do run into curl-issues often. Many times I didn’t even know, that in the end I was using libcurl for access before one of these obscure errors pops. For this reason, my weapon-of-choice is wget, it uses OpenSSL’s crypto and is fully compatible with pretty much everything else in a Linux-distro.

Anyway, this time I chose to research this to the bitter and. It took me about a month (calendar time) to resolve this. Of course I didn’t spend all my time and energy into this, it just took a very long time to get this one done properly & right.

The problem

One day, I was just tinkering something and ran a command:

$ curl –verbose https://packetstormsecurity.net/

. and it pulled a curl on me.

* About to connect() to packetstormsecurity.net port 443 (#0)
* Trying 198.84.60.198.
* Connected to packetstormsecurity.net (198.84.60.198) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* Server certificate:
* subject: CN=packetstormsecurity.com,OU=Domain Control Validated
* start date: May 31 18:04:40 2015 GMT
* expire date: May 31 18:04:40 2016 GMT
* common name: packetstormsecurity.com
* issuer: CN=Go Daddy Secure Certificate Authority – G2,
OU=http://certs.godaddy.com/repository/,
O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US
* NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER)
* Peer’s Certificate issuer is not recognized.

* Closing connection 0
curl: (60) Peer’s Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn’t adequate, you can specify an alternate file
using the –cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you’d like to turn off curl’s verification of the certificate, use
the -k (or –insecure) option.

I hate when that happens. Also I don’t know who forgot to do what, but it just won’t work and nobody in the entire Internet knows how to handle that.

Figuring out the details of the issue

This is the easy part:

* NSS error -8179 (SEC_ERROR_UNKNOWN_ISSUER)
* Peer’s Certificate issuer is not recognized.

In human language that reads: The problem is with HTTPS. The certificate used by the remote site is issued by a Certificate Authority (CA), that we don’t know of and because we don’t know it we won’t trust any certificates issued by it.

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none

In human that reads: There were three (3) places I tried looking for the root-certificate:

1. NSS is the Network Security Services -library created by Mozilla. Its database is located at: /etc/pki/nssdb
2. OpenSSL is the library/toolkit used by pretty much rest of your Linux for HTTPS-encryption. It has the trusted root-certificates at: /etc/pki/tls/certs/ca-bundle.crt
3. OpenSSL d >CApath ) for certificates.

After doing all three of those, no suitable CA was found and curl had to disconnect from the server and inform user about this lack-of-trust -issue.

Possible solutions

Ignore the issue and force curl to continue

There is a suggestion:
turn off curl’s verification of the certificate, use the -k (or –insecure) option

This goes right out the window, because I’d rather chew off my left arm than force a prefectly valid check to be ignored. I’d rather spend the time investigating the fix. But that’s me. Most of you don’t care. I do.

Add the missing certificate to ca-bundle.crt

Good idea, but . That file is reserved for the operating system / distro by OpenSSL. Actually curl uses this file only to make its own life easier so that curl doesn’t have to distribute a set of trusted CA certificates, it just piggy-backs with something OpenSSL has.

Since this approach is OpenSSL-specific there is a procedure for adding own CA root-certificates into your system. When a new CA-root needs to be installed the mechanism is not to copy the certificate into this big file. How to actually do it, we’ll get into that later.

The obvious problem with this approach is, that next time your distro gets a new CA-bundle one of two things will happen: 1) your changes will be overwritten and lost, you’ll have to add the CA-root again or 2) the new CA-bundle won’t be installed, because somebody messed up a file which he/she shouldn’t do. This is definitely not a good approach.

Implicitly specify the CA root-certificate file

Aa-ha! There is a command-line option for this purpose:

–cacert
(SSL) Tells curl to use the specified certificate file to verify
the peer. The file may contain multiple CA certificates. The
certificate(s) must be in PEM format. Normally curl is built to
use a default file for this, so this option is typically used to
alter that default file.

That’s the one I could use, if I’d like to do that every goddamn single time I curl for something. First I don’t want to do that every time and second, that command-line option isn’t available for me, as I was using a piece of software wrapped to use libcurl.

Add the missing CA root-certificate into NSS database to establish trust

This is the one I chose. This is also the one nobody gets solved.
If you can find precise information on the web how to fix this, please tell me. I’ve been browsing the net for partial and non-working solutions enough not to care for half-assed solutions which don’t work at the end.

Getting the missing certificate

Whatever we do (except just ignore the problem), the missing root-certificate needs to be located. With a little bit of googling I found a page Repository, Here’s a collection of important certificate documentation (https://certs.godaddy.com/repository/) at GoDaddy’s server. Sure, the initial impression was "whoa, that was easy!", but when I landed on the page, I realized that there were following root-certificates available for GoDaddy Certificate Chain – G2 to download:

1. GoDaddy Class 2 Certification Authority Root Certificate – G2
2. GoDaddy Secure Server Certificate (Intermediate Certificate) – G2
3. Microsoft to GoDaddy G2 Cross Certificate
4. GoDaddy G2 Code Signing Intermediate
5. GoDaddy Secure Extended Validation Code Signing CA – G2
6. GoDaddy Certificate Bundle for Microsoft Windows Driver Signing – G2
7. GoDaddy Certificate Bundles – G2
8. GoDaddy PKCS7 Certificate Intermediates Bundle (for Windows IIS) – G2
9. GoDaddy Certificate Bundles – G2 With Cross to G1
10. GoDaddy Certificate Bundles – G2 With Cross to G1, includes Root

Ok, which one will I need? Darn!

Luckily I know something about X.509 certificates and especially certificate extensions. There should be an AIA or Authority Information Access -section (see RFC 5280 section 5.2.7 for details) in the cert. At least most CAs provide that information to make people’s life easier.

First download the cert with a one-liner:

$ echo |
openssl s_client -connect packetstormsecurity.net:443
​ > /tmp/packetstormsecurity.net.cert

Btw. the one-liner will say dumb things like:

depth=0 OU = Domain Control Val > verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Val > verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = Domain Control Val > verify error:num=21:unable to verify the first certificate
verify return:1

That’s just vomit from the fact, that the certificate isn’t trusted. The important thing is, that the one-liner will result a text-file with lot of other garbage, but also the server certificate PEM. Luckily OpenSSL will ignore all the garbage when doing command:

$ openssl x509 -noout -text -in /tmp/packetstormsecurity.net.cert

That one will output a lot of stuff. Most if which are irrelevent for this purpose. The relevant things are:

Certificate:
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc.,
OU=http://certs.godaddy.com/repository/,
CN=Go Daddy Secure Certificate Authority – G2
X509v3 extensions:
X509v3 Certificate Policies:
Policy: 2.16.840.1.114413.1.7.23.1
CPS: http://certificates.godaddy.com/repository/
Authority Information Access:
OCSP – URI:http://ocsp.godaddy.com/
CA Issuers –
URI:http://certificates.godaddy.com/repository/gdig2.crt
X509v3 Authority Key Identifier:
keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE

Exactly what we needed! There is an AIA-block with a direct URL of http://certificates.godaddy.com/repository/gdig2.crt in it.

$ wget http://certificates.godaddy.com/repository/gdig2.crt
-O "/etc/pki/tls/certs/Go Daddy Secure Certificate Authority – G2.pem"

. and verify that certificate’s serial number:

$ openssl x509 -noout -text
-in /etc/pki/tls/certs/Go Daddy Secure Certificate Authority – G2.pem

Certificate:
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc.,
CN=Go Daddy Root Certificate Authority – G2
Subject: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc.,
OU=http://certs.godaddy.com/repository/,
CN=Go Daddy Secure Certificate Authority – G2
X509v3 extensions:
X509v3 Subject Key Identifier:
40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE
X509v3 Authority Key Identifier:
keyid:3A:9A:85:07:10:67:28:B6:EF:F6:BD:05:41:6E:20:C1:94:DA:0F:DE

Oh yes x 2!! The CA certificate has the correct serial number. It issued the failing certificate. This proof of correct CA-chain. We found the correct file.

Establishing trust to the new CA root-certificate in OpenSSL

This is the easy part. This one I have done hundreds of times.

First get a hash of the certificate:

$ openssl x509 -hash -noout
-in /etc/pki/tls/certs/Go Daddy Secure Certificate Authority – G2.pem

For this particular certificate, the hash is 27eb7704. The next thing is to instruct OpenSSL that this newly downloaded certificate is trusted by our server. It can be done like this:

$ ln -s /etc/pki/tls/certs/Go Daddy Secure Certificate Authority – G2.pem
/etc/pki/tls/certs/27eb7704.0

The idea is to symlink the downloaded file with a filename from the hash and suffix the file with a .0 (dot-zero).

Now we can verify, that our setup was done correctly (remember the "garbage" file we downloaded earlier):

$ openssl verify /tmp/packetstormsecurity.net.cert

The only valid output would be:

Anything else, and you fumbled it.

Additional step: Add all hashes of the certificate chain

Command line openssl -command is at level now, however that’s not how applications access certificates. Now this is where the CLI-command and library functionality differ. My box has /usr/lib64/libssl.so.10 to do the work for an application.

Looking at the SSL_CTX_use_certificate documentation, it’s evident that there are functions to add a known certificate bundle ( /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem in my box, symlinked via /etc/pki/tls/certs/ca-bundle.crt ), or a single certificate file. Not a directory of certificates, what openssl -command does. An application has to iterate the directory and add every certificate individually. For example in Perl, HTTPS-connections are typically created via IO::Socket::SSL -library. It accempts two options: SSL_ca_path and SSL_ca_file .

As the option of modifying the ca-bundle.crt file was abandoned already, using option SSL_ca_file is out. It leaves us with SSL_ca_path , which requires every certificate hash to be symlinked to the appropriate certificate PEM-file. That’s why the already done symlink won’t do it completely, two additional ones are required to get IO::Socket::SSL working properly:

$ ln -s ca-bundle.crt cbf06781.0
$ ln -s ca-bundle.crt f081611a.0

Where those two hashes come from is bit complex, but here goes:
The intermediate CA certificate we downloaded, Go Daddy Secure Certificate Authority – G2, was issued by:

$ openssl x509 -noout -issuer_hash
-in Go Daddy Secure Certificate Authority – G2.pem

. a certificate which has hash of cbf06781, which is already packed into ca-bundle.crt . Here things go weird, the Go Daddy Root Certificate Authority – G2 having hash cbf06781 is self-signed. However, during web-access that exact same certificate (with same serial number and all) is issued by a certificate having hash of f081611a. In ca-bundle.crt there is one with subject Go Daddy Class 2 Certification Authority. So, we need to add both to keep applications happy. Looks like somebody at Go Daddy really dropped the ball. Why should there be two separate CA certificates? Insane.

Actually, for example OpenSuSE Linux distro does that automatically to all bundle-certificates. The system is so stupid, that symlinkin all certificates is the only working method.

Establishing trust to the new CA root-certificate in NSS

Ok, this is the impossible part.

By lot of googling, poking around, failing, reading docs, tracing Curl, etc. I found out that there is a tool called certutil – Utility to manipulate NSS certificate databases. It seems to belong to package nss-tools. There is a man-page and some documentation at Network Security Services. But what’s happening and how should I proceed remains bit foggy.

There is a /etc/pki/nssdb/ , which we found in the beginning of this. That directory contains the NSS database in form of bunch of files. I found out that cert8.db and key3.db are completely obsoleted and any access methods having certutil -d /etc/pki/nssdb/ are completely useless, because they access only those files. Nobody/nothing uses those. Why are they there?

The files having effect are cert9.db and key4.db . The correct way of accessing those includes certutil -d sql:/etc/pki/nssdb . Notice the sql: -part difference. That’s the part causing most confusion.

To get the certificate into the DB run command on a single line:

certutil -d sql:/etc/pki/nssdb -A -t "C,C,C"
-n "Go Daddy Secure Certificate Authority – G2"
-i /etc/pki/tls/certs/Go Daddy Secure Certificate Authority – G2.pem

Now your NSS DB should list:

# certutil -d sql:/etc/pki/nssdb -L

Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Go Daddy Secure Certificate Authority – G2 C,C,C

The three Cs mean that the certificate in the DB is an authority for servers, e-mail and code signing. certutil docs say, that using ‘C‘ for intermediate certificates is discouraged, and I didn’t bother to check if that ‘C‘ is needed at all. But having that doesn’t break anything now the setup is done.

Testing

Now, running exactly the same command:

$ curl –verbose https://packetstormsecurity.net/

* About to connect() to dl.packetstormsecurity.net port 443 (#0)
* Trying 198.84.60.200.
* Connected to dl.packetstormsecurity.net (198.84.60.200) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* subject: CN=packetstormsecurity.com,OU=Domain Control Validated
* start date: May 31 18:04:40 2015 GMT
* expire date: May 31 18:04:40 2016 GMT
* common name: packetstormsecurity.com
* issuer: CN=Go Daddy Secure Certificate Authority – G2,
OU=http://certs.godaddy.com/repository/,
O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US

Yesh! It works!

One hell of a thing to get fixed, but now the trust has been established so that it reaches also Curl and any applications using libcurl .

Final words

This is a multi-mess.

First: Go Daddy messes up their certs. Why isn’t their Go Daddy Secure Certificate Authority – G2 in ca-bundle.crt ? Why are there two version of Go Daddy Root Certificate Authority – G2?

Second: Having NSS in a Linux is insane! Nobody else is using that for certificate storage. libcurl ‘s support for any own CAs is completely messed up and unusable.

Would you elaborate on your problem? Try to describe what you are doing and what error messages are you seeing.

See: How To Ask Questions The Smart Way by Eric Steven Raymond and Rick Moen
http://www.catb.org/esr/faqs/smart-questions.html

I actually walked down the path of trying to update my curl curl-ca-bundle.crt to work with a GoDaddy cert on my sandbox server. There were a few articles on the internet that explored the –cacert option to curl, but this turned out to be the wrong path for the actual issue.

It turns out my sandbox needed to also include the intermediate cert from GoDaddy along with the one for my domain. This fix works without any mods to curl, etc. See article here:

Also explained here how to server the fullchain, not the cert by itself:

What you do is add the GoDaddy intermediate cert to your test server. Then curl works without any mods.

Ok. The principle is, that root cert is your trust anchor. You should NOT add intermediate as one.

Your service is supposed to provide both the certificate for the service AND the intermediate CA. Logic there is that inter-certs must be as disposable as your service certs. An example of certificate trust chain can be found for example in my Let’s Encrypt -post (https://blog.hqcodeshop.fi/archives/391-Goodbye-CAcert.org-Welcome-Lets-Encrypt!.html).

If you need to add trust to the intermediate cert, something isn’t configured correctly. Assuming the scenario where inter-CA is compromized and it’s cert and all certs ever issued by it are revoked, a new inter-cert will be issued, your system will collapse like a house of cards. Your system MUST be built to resist that. To achieve the desired result, only the root-cert must be trusted.

You chose the easy way out. That’s ok. Majority of users will do that. That’s not what I would do, but . sometimes reality bites.

I came across this issue when migrating an SSL cert to a new server and switching from Apache to Nginx. After some troubleshooting tried concatenating cert with the GoDaddy bundle file. And that cleared up the curl issue.

In short my certificate chain was incomplete, but browsers were not complaining, only curl.

As I wrote in my post, curl in Linux is a tricky beast. It doesn’t use OpenSSL CA certificates, but uses its own NSS-based cert vault. Your distro guys don’t very likely know/care about that and have updated OpenSSL certificates, leaving curl short.

Actually, I did ask Mr. Stenberg about this, see https://blog.hqcodeshop.fi/archives/342-Mirado-Tech-Talks-HTTP2,-the-good,-the-bad-and-whats-next.html. Since he works for Mozilla who author NSS library his view won’t change, curl will default for NSS. For reasons beyond my comprehension, Linux distro makers don’t solve this for you and me and won’t compile their curl without NSS and with OpenSSL, that would solve the CA-issue completely. curl has all the features and library supports in the world, its just using them.

In macOS even curl uses the CA vault prov >Comments (4)

Please your help, for create the two additional symlinked.

Всего за
4 367,00 руб в год
Распродажа: сэкономьте 20%
5 459,00 руб в год при продлении 4

Всего за
9 359,00 руб в год
Распродажа: сэкономьте 20%
11 699,00 руб в год при продлении 4

Всего за
18 852,87 руб в год
Распродажа: сэкономьте 19%
23 399,00 руб в год при продлении 4

Всего за
9 553,51 руб в год
Распродажа: сэкономьте 21%
12 199,00 руб в год при продлении 4

Вот что вы получаете вместе с сертификатом SSL:

Мы упростили для вас выбор подходящего сертификата SSL.

SSL подтверждения домена (DV)
Сертификат

SSL подтверждения организации (OV)
Сертификат

SSL расширенной проверки (EV)
Сертификат

Почему стоит выбрать именно сертификат SSL от GoDaddy?

Мы вдохновляем предпринимателей на великие дела.

Мы гарантируем первоклассное обслуживание клиентов.

Мы и есть ваш Центр сертификации.

Еще больше причин приобрести сертификат SSL от GoDaddy!

Подчеркните индивидуальность своего бренда.

Предупреждение "Не защищено". Это плохой признак.

Более высокий рейтинг в поисковых системах.

Соответствие требованиям стандартов.

Завоюйте доверие клиентов.

Обеспечьте безопасность онлайн-транзакций и мобильных платежей.

Как работают сертификаты SSL

Сертификат SSL создает зашифрованный цифровой канал связи, который не позволяет злоумышленникам получить доступ к конфиденциальной информации клиентов:
именам пользователей, паролям, данным кредитных карт и не только.

Прежде всего, приобретите сертификат SSL.

Появляется значок замка.

Теперь всё в порядке!

Саманта С.
Знаток GoDaddy

Саманта С.
Знаток GoDaddy

Саманта С.
GoDaddy Знаток

Другие способы обеспечить безопасность веб-сайта.

Узнайте, какие еще продукты можно использовать, чтобы обезопасить свой веб-сайт от хакеров.

Создайте резервную копию веб-сайта и своих данных. На всякий случай.

От
119,00 руб в месяц

Защитите свой веб-сайт от хакеров.

От
356,06 руб в месяц

Название говорит само за себя — мы управляем сертификатами за вас.

От
796,13 руб в месяц

Часто задаваемые вопросы о сертификатах SSL

Как установить сертификат SSL?

Когда сертификат SSL будет выдан, мы отправим вам письмо. Дальше все зависит от хостинга вашего веб-сайта и параметров, указанных вами при покупке сертификата.

Если вы выбрали веб-хостинг, Конструктор веб-сайтов или Онлайн-магазин, мы обо всем позаботимся. Если ваш веб-сайт находится на сервере другой компании либо на нашем VPS или выделенном сервере, прочитайте эту статью.

О том, как установить сертификат SSL на Parallels Plesk Panel, cPanel или Microsoft IIS, рассказано здесь.

Что такое сертификат SSL?

Это цифровой сертификат, который использует технологию SSL (Secure Socket Layer), — протокол безопасных соединений. Сертификаты SSL подтверждают подлинность ресурса и зашифровывают данные, которые посетители отправляют на веб-сайт или получают с него. Это не позволяет злоумышленникам отслеживать передаваемую информацию.

Если ваш веб-сайт защищен сертификатом SSL, ваши клиенты могут быть уверены в том, что введенная ими информация конфиденциальна и невидима для киберпреступников. С GoDaddy установить сертификат и обеспечить безопасность сервера не составит труда.

Дополнительную информацию вы найдете в статье Что такое сертификат SSL.

В чем польза сертификата SSL на веб-сайте?

Сертификат SSL от GoDaddy дает вашим посетителям уверенность в том, что вы заботитесь об их личных данных. Он защищает конфиденциальную информацию ваших клиентов (например, имена, адреса, пароли и номера кредитных карт), шифруя данные при передаче с компьютера на веб-сервер. SSL — стандарт веб-безопасности, а сертификат сервера требуют большинство сервисов для электронной коммерции. Если вы планируете принимать оплату банковскими картами на своем веб-сайте, вам потребуется такой сертификат.

Дополнительную информацию вы найдете в статье Как работает сертификат SSL.

Как люди узнают о безопасности моего веб-сайта?

По обозначениям. При этом способ создания веб-сайта не имеет значения. Для большинства несложных страниц можно написать код вручную на языке HTML.

Когда человек открывает веб-сайт, защищенный сертификатом SSL, в адресной строке браузера отображается значок замка и префикс https://. Хотя большинство интернет-пользователей знают об этих маркерах, вы можете добавить на свой веб-сайт печать, подтверждающую его надежность. Нажав на нее, посетители смогут увидеть статус сертификата и подробную информацию о нем. Это позволит им убедиться, что отправлять конфиденциальные данные на ваш веб-сайт безопасно.

Чем отличается стандартный сертификат SSL от премиум-сертификата SSL?

При посещении любого веб-сайта, защищенного сертификатом SSL, в адресной строке отображается префикс https://. Если веб-сайт защищен премиум-сертификатом EV SSL, адресная строка становится зеленой. Это указывает посетителям на то, что юридическое и физическое существование компании подтверждено в соответствии со строгими отраслевыми стандартами.

Для получения премиум-сертификата EV SSL GoDaddy требуется наиболее тщательная проверка. Мы проверяем владение доменом и законность вашей компании, подтверждая юридическое название, адрес, номер телефона и другую информацию. Процесс занимает около 30 дней. На это время мы бесплатно предоставляем вам стандартные сертификаты SSL, чтобы ваши транзакции были защищены, пока вы ждете новый сертификат.

Почему стоит выбрать сертификат SSL от GoDaddy?

Наши сертификаты SSL работают с неограниченным числом защищенных серверов. Они поддерживают шифрование до 2048 бит и распознаются всеми основными браузерами для компьютеров и мобильных устройств. Кроме того, мы предоставляем лучшую в отрасли поддержку по телефону. Технически разницы между сертификатами SSL от GoDaddy и других компаний нет. Просто наши стоят дешевле. Неудивительно, что наша компания — крупнейший поставщик новых сертификатов SSL в мире.

Что такое универсальный сертификат SSL?

Универсальный сертификат SSL защищает основной домен и неограниченное количество его субдоменов. Например, с помощью одного такого сертификата можно защитить страницы www.coolexample.com и blog.coolexample.com.

Универсальные сертификаты защищают общее имя и все субдомены на уровне, указанном вами при отправке запроса.

Сертификат SSL какого типа мне нужен?

Чтобы подобрать оптимальный сертификат SSL, ответьте на перечисленные ниже вопросы.

Где вы находитесь?

Мы выпускаем сертификаты для пользователей со всего мира за несколькими исключениями. Список поддерживаемых стран находится здесь.

У вас коммерческий или личный веб-сайт?

Если вы не продаете товары на личном веб-сайте, вам подойдет стандартный сертификат SSL (DV). Его же можно добавить и на веб-сайт информационного характера. Для веб-сайтов электронной коммерции используйте стандартный сертификат SSL (DV) на один домен или премиум-сертификат SSL (EV).

Сервер веб-хостинга какого типа вы используете?

Наши сертификаты SSL подходят для большинства конфигураций хостинга и серверов. Для защиты нескольких доменов на базе Microsoft Exchange Server 2007, Exchange Server 2010 или Live® Communications Server используйте мультидоменный сертификат SSL (UCC).

Сколько отдельных доменов нужно защитить?

Универсальные сертификаты SSL защищают основной домен и несколько субдоменов. Например, универсальный сертификат для защиты домена *.coolexample.com также будет распространяться на субдомены (shop.coolexample.com, www.coolexample.com и т. д.).

Сертификаты UCC SSL охватывают несколько доменов, субдоменов и веб-сайтов. Например, с их помощью вы можете защитить домены www.coolexample.com, mail.coolexample.com и www.awesomeexample.com.

Нужен ли вам сертификат SSL, поддерживающий технологию Intel vPro для удаленного управления компьютерами?

Вам подойдет люкс-сертификат (OV).

Как долго ждать сертификат SSL?

Оформление стандартных сертификатов SSL (DV) обычно занимает не больше пяти минут. На оформление люкс-сертификатов SSL (OV) может уйти от трех до пяти рабочих дней, поскольку нам нужно проверить не только право владения доменом, но и существование организации или компании, указанной в заявке.

Для получения премиум-сертификатов (EV) потребуется пройти тщательную проверку. Прежде чем подать заявку, соберите полные сведения о своей компании, в частности регистрационный номер, имя агента по регистрации и другие необходимые юридические данные.

Как создать запрос о подписи сертификата (CSR)?

Это зависит от программного обеспечения на вашем веб-сервере. Подробнее…

Инструкции по созданию CSR в Plesk Panel, cPanel и Microsoft IIS можно найти здесь.

Что такое сертификат UCC?

Сертификат UCC (Unified Communications Certificate) — это сертификат SSL, который защищает несколько доменных имен и несколько узлов в рамках одного домена. Один такой сертификат позволяет защитить основное доменное имя и до 99 дополнительных имен субъекта (SAN). Например, один сертификат UCC можно использовать для защиты доменных имен www.domains1.com, www.domains2.net и www.domains3.org.

Сертификаты UCC поддерживают общий хостинг и отлично подходят для работы с Microsoft® Exchange Server 2007, Exchange Server 2010 и Microsoft Live® Communications Server. Однако печать сайта и сведения о получателе сертификата содержат только основное доменное имя. Обратите внимание, что дополнительные хостинг-аккаунты также будут указаны в сертификате. Если вы не хотите, чтобы между веб-сайтами визуально прослеживалась связь, не используйте сертификат этого типа.

Сколько отдельных доменов можно защитить с помощью протокола https?

В зависимости от конфигурации веб-сайта вам может потребоваться сертификат SSL для защиты нескольких доменов.

Универсальные сертификаты SSL защищают все субдомены доменного имени. Например, один сертификат для *.coolexample.com будет действовать для shop.coolexample.com, www.coolexample.com и всех остальных субдоменов.

Сертификаты UCC SSL могут защищать несколько субдоменов, уникальных доменных имен и веб-сайтов. Например, их можно использовать для защиты доменов www.coolexample.com, mail.coolexample.com и www.awesomeexample.com.

Хотите узнать больше о сетификатах SSL?

В нашей Базе знаний вы найдете всю необходимую информацию о настройке и использовании сертификатов SSL.

Для личного домена сети доставки содержимого Azure (CDN) в конечной точке Azure CDN уровня "Стандартный" от Майкрософт, когда вы включите функцию HTTPS, используя свой собственный сертификат, нужно создать SSL-сертификат с помощью разрешенного центра сертификации (ЦС). For an Azure Content Delivery Network (CDN) custom domain on an Azure CDN Standard from Microsoft endpoint, when you enable the HTTPS feature by using your own certificate, you must use an allowed certificate authority (CA) to create your SSL certificate. В противном случае при использовании недопустимого ЦС или самозаверяющего сертификата ваш запрос будет отклонен. Otherwise, if you use a non-allowed CA or a self-signed certificate, your request will be rejected.

Возможность использования собственного сертификата для включения пользовательского HTTPS доступна только с профилем Azure CDN уровня "Стандартный" от Майкрософт. The option of using your own certificate to enable custom HTTPS is available only with Azure CDN Standard from Microsoft profiles.

При создании собственного сертификата разрешены следующие ЦС: The following CAs are allowed when you create your own certificate: