Sec error inadequate cert type

Howdy,

I run a Private Certificate Authority for my personal use and just to learn about SSL Certs. However, with the current build of FireFox I’m on ( 31 ) I can no longer visit sites I’ve secured with SSL Certs signed by this certificate authority, even though these SSL certs work just perfectly fine in Chrome and Internet Explorer. I keep getting a «sec_error_inadequate_cert_type» error. I can only assume that the certs I’ve been issuing are incorrect in some way, but the error is so vague and the error page doesn’t specify more.

I only discovered this when I realized some of my SSL certs had expired, and I went to re-issue them.

One of the certs that hasn’t expired yet but is experiencing problems can be found here:

* https://forums.silicateillusion.org

One of the Certs I’ve tried re-issuing, matching fields included as closely as I can to a Google SSL cert that I looked up is here:

* https://phpmyadmin.endofevolution.com

These certificates were generated using the application called SimpleAuthority, found here: http://simpleauthority.com/

A Site like Networking4All.com seems to believe the Certs are valid, excepting the CA that is Self Signed: http://www.networking4all.com/en/support/tools/site+check/report/?fqdn=phpmyadmin.endofevolution.com&protocol=https

Interestingly enough, using a different site like SSLShopper shows an error similar to FF31: http://www.sslshopper.com/ssl-checker.html#hostname=https://phpmyadmin.endofevolution.com

The certs are running on an Apache Web server: Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.10

The CA Cert is in FireFox’s store as trusted.

If needed, I can provide certs.

Sec error inadequate cert type

Полезная информация

Страницы: 1

№1 26-06-2008 17:39:56

Ошибка сертификата при подключении по https

При попытке подключиться к файрволу D-Link DFL-210 по протоколу https выдается страница со следующей ошибкой:
«Ошибка при установлении защищенного соединения. При соединении с 192.168.1.1:444 произошла ошибка. Этот тип сертификата не одобрен для приложения. (Код ошибки: sec_error_inadequate_cert_type)«.

Я понимаю, что в устройстве прописан неверный сертификат (вернее, сертификат с неверными параметрами), однако это устройство не имеет возможности управлять параметрами сертификата, а подключиться к нему очень хочется. Можно ли как-нибудь обойти эту ошибку?

№2 26-06-2008 17:45:32

Re: Ошибка сертификата при подключении по https

tdr
Скорее всего нет. Разве что поискать прошивку поновее или использовать другой браузер (IE точно такие ошибки игнорирует). Ошибка очень серьезная — перепутаны роли сертификата (вместо серверного сделан клиентский, что является грубым нарушением).

Все микробы умрут

№3 27-06-2008 09:09:43

Re: Ошибка сертификата при подключении по https

Это конечно понятно, но почему бы не отдать такую ситуацию на откуп пользователя, пусть он сам решает, идти дальше, или отказаться. Мне кажется это более логично, чем просто блокировать доступ без вариантов.

№4 27-06-2008 10:26:41

Re: Ошибка сертификата при подключении по https

tdr
С безопасностью не шутят.

Все микробы умрут

№5 30-06-2008 10:30:54

Re: Ошибка сертификата при подключении по https

Просмотрел свойства сертификата на устройстве и вот что получилось:
CommonName совпадает с адресом устройства (CN=192.168.1.1), по срокам ключ валиден, роль сертификата «Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)», использование ключа «Цифровая подпись, Шифрование ключей, Шифрование данных, Согласование ключей, Подписывание сертификатов, Автономное подписание списка отзыва (CRL), Подписывание списка отзыва (CRL)», сертификат самоподписанный. Так что же заставляет ФФ3 выдавать ошибку «»Ошибка при установлении защищенного соединения. При соединении с 192.168.1.1:444 произошла ошибка. Этот тип сертификата не одобрен для приложения. (Код ошибки: sec_error_inadequate_cert_type)».» и блокировать доступ к устройству?

№6 05-07-2008 01:03:29

Re: Ошибка сертификата при подключении по https

tdr
Если считаете, что это баг, то вам в https://bugzilla.mozilla.org/enter_bug.cgi

Do not meddle in the affairs of Wizards, for they are subtle and quick to anger.

Источник

Sec error inadequate cert type

I run a Private Certificate Authority for my personal use and just to learn about SSL Certs. However, with the current build of FireFox I’m on ( 31 ) I can no longer visit sites I’ve secured with SSL Certs signed by this certificate authority, even though these SSL certs work just perfectly fine in Chrome and Internet Explorer. I keep getting a «sec_error_inadequate_cert_type» error. I can only assume that the certs I’ve been issuing are incorrect in some way, but the error is so vague and the error page doesn’t specify more.

I only discovered this when I realized some of my SSL certs had expired, and I went to re-issue them.

One of the certs that hasn’t expired yet but is experiencing problems can be found here:

One of the Certs I’ve tried re-issuing, matching fields included as closely as I can to a Google SSL cert that I looked up is here:

These certificates were generated using the application called SimpleAuthority, found here: http://simpleauthority.com/

Interestingly enough, using a different site like SSLShopper shows an error similar to FF31: http://www.sslshopper.com/ssl-checker.html#hostname=https://phpmyadmin.endofevolution.com

The certs are running on an Apache Web server: Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.10

The CA Cert is in FireFox’s store as trusted.

If needed, I can provide certs.

Выбранное решение

I discovered the problem: The CA Certificate I was using had extended usage included.

I confirmed this by generating a new test CA with the the extended usage field excluded, then generating a new SSL Cert The certificate verifies properly now.

While I am relieved I have figured out what the problem is, being so vague with the error message is making me lean towards another browser for primary usage. The fact it took me 4 days and an extremely large amount of work to figure out why this was occurring was unacceptable, all because the error description was generic and included absolutely no details what so ever.

Все ответы (6)

I get this error in Google Chrome as well.

Current Firefox releases no longer allow to add an exception with the switch to PKIX. You would have to disable PKIX temporarily when visiting a site that doesn’t work with it.

Note that you won’t be able to do this with the next 33 Firefox version as support for this pref has been removed.

• Bug 975229 — Remove NSS-based certificate verification

There are more changes to certificates, see:

Изменено 10 сентября 2014 г., 20:33:57 -0700 cor-el

I however, do not. It’s something specific to Firefox I seem to be having. Maybe I’m running an outdated version of Chrome? Which would be hard seeing as chrome itself says it’s up to date: Version 37.0.2062.120 m

I appreciate the link to Bug 1034124, However the SSL certificate itself IS NOT self signed. Only the CA is, which signed the SSL Cert. I guess what I mean to be asking is. Is Firefox Rejecting my SSL Cert, because my CA Is Self Signed?

I also offer the CA Cert for download since no one would have the cert in their stores. Would this also affect it?

I’ve attached a screen shot of the error I’m getting so that it’s available for the ticket. The following is also the «plaintext» verison of the error I’m getting:

«Certificate type not approved for application.»

I finally found a tool online that will show me the guts of the certificate: http://certlogik.com/ssl-checker/phpmyadmin.endofevolution.com/

Everything seems to be good.

Выбранное решение

I discovered the problem: The CA Certificate I was using had extended usage included.

I confirmed this by generating a new test CA with the the extended usage field excluded, then generating a new SSL Cert The certificate verifies properly now.

While I am relieved I have figured out what the problem is, being so vague with the error message is making me lean towards another browser for primary usage. The fact it took me 4 days and an extremely large amount of work to figure out why this was occurring was unacceptable, all because the error description was generic and included absolutely no details what so ever.

I however, do not. It’s something specific to Firefox I seem to be having. Maybe I’m running an outdated version of Chrome? Which would be hard seeing as chrome itself says it’s up to date: Version 37.0.2062.120 m I appreciate the link to Bug 1034124, However the SSL certificate itself IS NOT self signed. Only the CA is, which signed the SSL Cert. I guess what I mean to be asking is. Is Firefox Rejecting my SSL Cert, because my CA Is Self Signed? I also offer the CA Cert for download since no one would have the cert in their stores. Would this also affect it? I’ve attached a screen shot of the error I’m getting so that it’s available for the ticket. The following is also the «plaintext» verison of the error I’m getting: «Certificate type not approved for application.»

I however, do not. It’s something specific to Firefox I seem to be having. Maybe I’m running an outdated version of Chrome? Which would be hard seeing as chrome itself says it’s up to date: Version 37.0.2062.120 m I appreciate the link to Bug 1034124, However the SSL certificate itself IS NOT self signed. Only the CA is, which signed the SSL Cert. I guess what I mean to be asking is. Is Firefox Rejecting my SSL Cert, because my CA Is Self Signed? I also offer the CA Cert for download since no one would have the cert in their stores. Would this also affect it? I’ve attached a screen shot of the error I’m getting so that it’s available for the ticket. The following is also the «plaintext» verison of the error I’m getting: «Certificate type not approved for application.»

I had the same issue, what i did was, copy two cert from your computer 1 is trusted rootCA cert 2.root CA1 from mmc console save those two cert into local computer then import it into mozilla firefox, under options->Advanced-> Certificates->view certificate->authorities->import-> restart it should work

Изменено 16 февраля 2015 г., 23:48:37 -0800 Brad

Источник

SecurityEngineering/x509Certs

Contents

A Web PKI x509 Certificate Primer

X.509 (in this document referred as x509) is an ITU standard to describe certificates. Three versions of the x509 standard have been defined for web-pki. In this document we will be referring to the current standard in use for web pki: x509 v3, which is described in detail in RFC 5280. In general x509 certificates bind a signature to a validity period, a public key, a subject, an issuer, and a set of extensions. The extensions define extra properties of the certificate such as extra attributes of the certificate or constraints on the use of the certificate. In order for a certificate to be valid these three requirements must be met:

1. There is a verification path from the site certificate to a trusted certificate of the user agent (ie if you follow the issuer path you will end on a self-signed certificate that is considered trusted by the browser).
2. The attributes of the certificates in the verification path have valid parameters for that verification (for example the validity period of all the certificates are valid for the time the verification is being done)
3. Revocation checks are considered OK for that particular validation.

One issue that is not commonly known is that the x509 trust graph is not a forest (a bunch of trees where each root is a trusted root) but a cyclic graph, where the same key/issuer can be a root or an intermediate for another root in the browsers key store (when roots create intermediates for each other it is called cross-signing).

Extensions

While RFC 5280 defines 16 extensions for webpki in this document we will be describing the six extensions we considered critical for understanding. Certificates can have other extensions not described on RFC 5280, but that is out of the scope of this document. Extensions can be marked as critical or non-critical, conforming certificate verification libraries should stop processing verification when encountering a critical extension that they do not understand ( and should continue prococessing if the extension is marked as non-critical) mozila::pkix has this behavior.

Subject Alternate Name

This extension defines what other names (such as DNS names) are valid for this certificate. This allows for a certificate to be used for more than one FQDN, for example you can have a certificate that is valid for both a.example.com and b.example.com

Basic Constraints

This allows certificates to be asserted as issuing certificates (it is mandatory for CA certificates). It can also be used to express the maximum depth of the trust path from the CA.

Key Usage

This extension is used to constrain the purpose for the key in the certificate. More than one key usage can be asserted. Examples of key usages are: digitalSginature, keyEncipherement, dataEncipherement, keyCertSig, crlSign. For CA certificates the keyCertSign bit MUST be asserted.

Extended Key Usages

This is another bitfield to constrain the usages of the key of the certificate. Its is directed mostly at what type of application the certificate was issued for. Examples of extended key usages are: serverAuth, clientAutn and OCSPSigning. For end-entity certificates for PKI this extension is required to exist with the serverAuth bit asserted.

Name Constraints

This is an extension exclusive for CA and indicates limits on the name space for its children. This is one of the most powerful extensions for businesses to have to help limit risk imposed by losing the private key of the CA.

This extension is primarily used to to describe the OCSP location for revocation checking. It is mandatory for certificates that chain up to a root in the Mozilla CA program.

Self Signed Certs

These are the steps to generate a certificate for www.example.com. Replace this value with the actual server name in the steps below.
1. Generate key:

«openssl genpkey -algorithm RSA -out key.pem -pkeyopt rsa_keygen_bits: 2048»
2048 is considered secure for the next 4 years.

«openssl req -new -key key.pem -days 1096 -extensions v3_ca -batch -out example.csr — utf8 -subj ‘/CN=www.example.com’
Make a new Certificate Signing Request (CSR) that will be valid for 3 years.

3. Write extensions file (make a new file with name openssl.ss.cnf with the following contents)

basicConstraints = CA:FALSE
subjectAltName =DNS:www.example.com
extendedKeyUsage =serverAuth

4. Self-sign csr (using SHA256) and append the extensions described in the file

«openssl x509 -req -sha256 -days 3650 -in example.csr -signkey key.pem -set-serial $ANY_INTEGER -extfile openssl.ss.cnf -out example.pem»

You can now use example.pem as your certfile

CAs Included in Firefox

When you visit a secure website, Firefox will validate the website’s certificate by checking that the certificate that signed it is valid, and checking that the certificate that signed the parent certificate is valid and so forth up to a root certificate that is known to be valid. This chain of certificates is called the Certificate Hierarchy.

If your certificates will only be used to verify one domain (e.g. *.yourcompany.com) but you want others outside of your organization to be able to browse to your website using https without having to manually import a root certificate, then you can get an SSL certificate from one of the CAs who already have a root certificate included in the major browsers.

Firefox uses a default set of X.509v3 root certificates for various Certification Authorities (CAs). The root certificates included by default have their «trust bits» set to indicate if the CA’s root certificates may be used to verify certificates for SSL servers, S/MIME email users, and/or digitally-signed code objects without having to ask users for further permission or information.

CAs apply to have their root certificates included by default in Mozilla products by following the Mozilla CA Certificate Policy and applying for inclusion as per CA:How_to_apply. Users may override the default root certificate settings using the Certificate Manager.

Running your Own CA

If you are going to have your own CA, we recommend building 3 certificates: a long term root cert, a medium term intermediate cert, and a short term end-entity cert. This type of hierarchy allows for a relatively simple long term root to be distributed to clients, and some flexibility on the intermediate cert so that you can change parameters based on best practices and security research.

Generate your CA Root

Update *.example.com and *.example.net below to match your domains.

• You are the domain owner of *.example.com and *.example.net.
• Your computer is not connected to the internet.

Steps to generate your CA root certificate:

1. Generate key
   • «openssl genpkey -algorithm RSA -out rootkey.pem -pkeyopt rsa_keygen_bits: 4096»
   • 4096 is considered secure for the next 15 years.
2. Generate csr
   • «openssl req -new -key rootkey.pem -days 5480 -extensions v3_ca -batch -out root.csr — utf8 -subj ‘/C=US/O=Orgname/OU=SomeInternalName’
   • Make a new Certificate Signing Request (CSR) that will be valid for 15 years.
3. Write extensions File (openssl.root.cnf)
   • basicConstraints = critical, CA:TRUE
   • keyUsage = keyCertSign, cRLSign
   • subjectKeyIdentifier = hash
   • nameConstraints = permitted;DNS:example.com,permitted;DNS:example.net
4. Self-sign csr (using SHA256) and append the extensions described in the file
   • «openssl x509 -req -sha256 -days 3650 -in root.csr -signkey rootkey.pem -set-serial $ANY_SMALL_INTEGER -extfile openssl.root.cnf -out root.pem»

Now you have CA pem file with its associated key.

The following steps create an intermediate cert that is valid for 8 years.

1. Generate key
   • «openssl genpkey -algorithm RSA -out r=intkey.pem -pkeyopt rsa_keygen_bits: 3072»
   • A 3072 bit key is considered secure for the next 8 years.
2. Generate csr
   • «openssl req -new -key intkey.pem -days 2922 -extensions v3_ca -batch -out int.csr — utf8 -subj ‘/C=US/O=Orgname/OU=SomeInternalName2’
   • Make a new Certificate Signing Request (CSR) that will be valid for 8 years.
3. Write extensions File (openssl.int.cnf)
   • basicConstraints = critical, CA:TRUE
   • authorityKeyIdentifier = keyid, issuer
   • subjectKeyIdentifier = hash
   • keyUsage = keyCertSign, cRLSign
   • extendedKeyUsage =serverAuth
   • authorityInfoAccess = OCSP;URI:http://ocsp.example.com:8888/
4. Sign the intermediate csr with the root key and the intermediate extensions
   • «openssl x509 -req -sha256 -days 2922 -in int.csr -CAkey rootkey.pem -CA root.pem -set_serial $SOME_LARGE_INTEGER -out int.pem -extfile openssl.int.cnf»

Generate the end entity certificate

Update www.example.com below to match your domain.

1. Generate key
   • «openssl genpkey -algorithm RSA -out eekey.pem -pkeyopt rsa_keygen_bits: 2048»
   • 2048 is considered secure for the next 4 years.
2. Generate csr
   • «openssl req -new -key key.pem -days 1096 -extensions v3_ca -batch -out example.csr — utf8 -subj ‘/CN=www.example.com’
   • Make a new Certificate Signing Request (CSR) that will be valid for 3 years.
3. Write extensions file (make a new file with name openssl.ss.cnf with the following contents)
   • basicConstraints = CA:FALSE
   • subjectAltName =DNS:www.example.com
   • extendedKeyUsage =serverAuth Security Notes

There are several organizations that provide recommendations regarding the security parameters for key/hash sizes given current computational power. For the end date of the root cert created following the instructions in this page (year 2017). These are the recomendations of bit sizes (from http://www.keylength.com/):

In other words, SHA1 is now deprecated for new uses. We should use at least 3072 key sizes and at least a 256 ECC curve. Thus the recommendation here is for the root to be 4096 if using RSA and p384 for the root key. (p384 also chosen for compatibility as most SSL/TLS implementations support this part of suite B).

Error Codes in Firefox

Here are some common errors that might be encountered when working with certificates in Firefox.

Источник

Certs I used, issued with vault internal CA does not work with firefox, it throws sec_error_inadequate_cert_type. Nothing else that I’ve seen except for firefox (version 42.0) complains about this. (Safari, Chrome, curl, wget, javax.net.ssl.HttpsURLConnection are all happy with the resulting CA and client certs)

First I build vault from master, mount the pki backend, create a CA, and add the role I call test. Finally I issue a test cert for semester.test.

./vault -version
Vault v0.5.0-dev (b2e172ede807394fadf845466a3371f27086899b)
./vault mount pki
./vault  mount-tune -max-lease-ttl=87600h pki
./vault write pki/root/generate/internal common_name="Test CA" ttl=87600m
./vault write pki/roles/test allowed_domains="test" allow_subdomains="true" max_ttl="17520h"
./vault write pki/issue/test common_name=semester.test ttl=200h

Using the cert and key return from the vault write pki/issue/test common_name=semester.test ttl=200h command, I start a ssl server.

gnutls-serv --x509certfile /tmp/semester.test.pem --x509keyfile /tmp/semester.test.key.pem
Set static Diffie-Hellman parameters, consider --dhparams.
HTTP Server listening on IPv4 0.0.0.0 port 5556...done
HTTP Server listening on IPv6 :: port 5556...done

If I now go to the page with curl or wide range of different programs, it works.

This works:

curl https://semester.test:5556/ --cacert /tmp/test_ca.crt
wget https://semester.test:5556/ --ca-certificate /tmp/test_ca.crt

But, when using firefox (version 42.0), after importing my rest_ca.crt Root CA, it says Secure Connection Failed, with the error code: «Error code: sec_error_inadequate_cert_type».

This bz on mozilla.com seems to be relevant

When a private root CA has an extendedKeyUsage extension set it its certificate, firefox 31 will refuse to talk to servers certified by it, even if the root CA’s cert has been explicitly loaded and trusted as an authority for «identifying web sites». The error is SEC_ERROR_INADEQUATE_CERT_TYPE.

In that bugzilla, an article supposedly from the CA / Browser Forum is referenced. In Appendix B it says:

Root CA Certificate
Root Certificates MUST be of type X.509 v3.
[…]
extendedKeyUsage
This extension MUST NOT be present.

But, on my CA cert, that I generated from vault, using in the steps above:

-----BEGIN CERTIFICATE-----
MIIDQDCCAiigAwIBAgIUDeXwO+kKdepa++bhohll7dBWMc8wDQYJKoZIhvcNAQEL
BQAwEjEQMA4GA1UEAxMHVGVzdCBDQTAeFw0xNjAxMjkxMzI5MzJaFw0xNjAzMzAw
OTI5MzJaMBIxEDAOBgNVBAMTB1Rlc3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDAm33l0Cjo1kYDM5bMAPsbuLABBKPfJZCsWdQWTWROA9xdlZBz
M5WN5RtGPtfNobX9qBxeCqn0X9xJL7ee8e9I/IJc4eZSIUTVIpeKpUeE/Yc7nLqx
tQ7GgMavpGv4UcsWV8vhM62G6wQ8whMvWyRXQZ4oREfTcFcX2+lz/d6yVN60AKqB
tvSoIxngO9Frhp4rDrmb0PHQOo95DKaBlW5LhqhxhsL2NNgGSpe7zlmCXmJz0Jsk
Q4049O94DyCx004lbTXjK5HUInG7he3nmTgWrcGMI2kA7s5uOqyBuJnh0+1qqW1Y
JSL5a4RXjFSWzIzwRYR+1RIIeatqdlndh/75AgMBAAGjgY0wgYowDgYDVR0PAQH/
BAQDAgGuMBMGA1UdJQQMMAoGCCsGAQUFBwMJMA8GA1UdEwEB/wQFMAMBAf8wHQYD
VR0OBBYEFNIyv19n5H7Aku+I4LYpmEcvAtQdMB8GA1UdIwQYMBaAFNIyv19n5H7A
ku+I4LYpmEcvAtQdMBIGA1UdEQQLMAmCB1Rlc3QgQ0EwDQYJKoZIhvcNAQELBQAD
ggEBABBgthjazVvG8XexiwrntRRap34yKtueELfO9EQTUlVEdpVwxeITx03xSBpL
8T+v+FiUS1OPp+KnIy4b+k8tR3czUPXZO0c9VN9hz+dAOSyr3xHqSn6ObKvibh+B
Z36yEAX45iGQdQupvKjuadI3uqXm2HHhTNppBTw6BCF3ZpqzQmaxMf+C/aeOSCuu
Ed/0EX9nO+zmFYbSmDG27RQzng2rDDrfiG3NG0/Oisj4CoIdA4Tzrp84uJ+Lgdv4
00//4t0bkndo07ztdPy5PR+SJ32bMSy+2SLQqBvjQnifRJZoxyvGDKu9O25s6HF1
bhi3LZI7zQSWI7ZSJFhmtqmIn4o=
-----END CERTIFICATE-----

It does contain this extension.

            X509v3 Extended Key Usage:
                OCSP Signing

I am no subject-matter expert, and am by no means sure that there could be no use cases where a CA should not have the eKU on it, but I think it would be good if vault could generate Root CA:s withot X509v3 Extended Key Usage.

Either way I am happy as long as I can create certificates from vault, which works well with firefox.

mihmig	#1 Оставлено : 29 августа 2016 г. 14:51:39(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 18.05.2016(UTC) Сообщений: 112	Установлено: Windows Server 2008 R2 Standart x64 у пользователя права администратора КриптоПро CSP версия продукта 3.9.8227 (ядра СКЗИ 3.9.8001 КС2) Web-сервер nginx версии 1.10.1 с поддержкой шифрования по ГОСТ взятый из https://github.com/deemru/nginx/releases/latest Сертификат сервера сгенерирован в тестовом УЦ компании КриптоПро: https://www.cryptopro.ru/certsrv/certrmpn.asp Сервер nginx запускается без ошибок, но при попытке открыть URL https://localhost/ Браузеры выдают такую ошибку: Internet Explorer 11.0.9600.18426 (ОС только что скачала все обновления и перезагрузилась) Сертификат безопасности этого веб-сайта ненадежен Мы рекомендуем вам закрыть эту веб-страницу и не работать с данным веб-сайтом. Chromium Версия 52.0.2743.82 сборка взята из http://update.cryptopro.ru/chromium-gost/ Этот сайт не может обеспечить безопасное соединение Сайт 127.0.0.1 отправил недействительный ответ. ERR_SSL_PROTOCOL_ERROR CPFox 45.1.2 взятый из http://cryptopro.ru/products/cpfox An error occurred during a connection to localhost. Certificate type not approved for application. Error code: SEC_ERROR_INADEQUATE_CERT_TYPE В чём модет быть дело? Сертификат, конфиг и лог-файл сервера прикладываю (*.conf и *.crt файлы переименованы в txt, т.к. форум не даёт прикреплять файлы с этими расширениями). error.log (172kb) загружен 2 раз(а).

Захар Тихонов	#2 Оставлено : 29 августа 2016 г. 15:06:40(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 17.08.2015(UTC) Сообщений: 3,074 Откуда: Калининград Сказал «Спасибо»: 36 раз Поблагодарили: 552 раз в 529 постах	Здравствуйте. Тут довольно все логично. IE говорит что нет доверия, т.к. в сертификате нет слова в CN «localhost» или в дополнительном имени субъекта.
Техническую поддержку оказываем тут. Наша база знаний.

mihmig	#3 Оставлено : 29 августа 2016 г. 16:15:25(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 18.05.2016(UTC) Сообщений: 112	Хм, переформировал сертификат на localhost. Internet Explorer и Chromium соединились по TLSv1.0 CPFox отказался: An error occurred during a connection to localhost. security library: no security module can perform the requested operation. Error code: SEC_ERROR_NO_MODULE Что-то в нём нужно настроить? И ещё: почему-то заработало только после того как закомментировал опцию: ssl_protocols SSLv3 TLSv1.1 TLSv1.2; в nginx.conf

Захар Тихонов	#4 Оставлено : 29 августа 2016 г. 17:09:49(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 17.08.2015(UTC) Сообщений: 3,074 Откуда: Калининград Сказал «Спасибо»: 36 раз Поблагодарили: 552 раз в 529 постах	Так в CPFox получилось или нет? Если нет, то попробуйте в cpfox включить принудительного TLS 1.0 В about:config поменяйте значение security.tls.version.min и security.tls.version.max в 1, что соответствует TLS 1.0
Техническую поддержку оказываем тут. Наша база знаний.

mihmig	#5 Оставлено : 29 августа 2016 г. 17:14:01(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 18.05.2016(UTC) Сообщений: 112	Да, в CPFox получилось после изменения этих настроек: security.tls.version.min = 1 security.tls.version.max =1 ув. tikhonov скажите, а в «обычном» FireFox (или Chrome) можно добиться работы через GOST SSL и если нет то почему?

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Problem

curl rejects the CA certificate below with 60) Certificate type not approved for application for SEC_ERROR_INADEQUATE_CERT_TYPE. I would like to understand the reason.

SEC_ERROR_INADEQUATE_CERT_TYPE

A certificate has an extended key usage extension that does not assert a required usage, or an end-entity certificate asserts the id-kp-OCSPSigning usage when it shouldn’t

Because as far as I looked at the RFC 3218, it looks all the required extended key usage extensions are asserted.

The curl command and reply

$ sudo curl -ivL 
>     --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt 
>     --key  /etc/kubernetes/pki/apiserver-kubelet-client.key 
>     --cacert /var/lib/kubelet/pki/kubelet.crt 
> https://ip-172-31-4-117.us-west-1.compute.internal:10250/healthz
*   Trying 172.31.4.117...
* TCP_NODELAY set
* Connected to ip-172-31-4-117.us-west-1.compute.internal (172.31.4.117) port 10250 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /var/lib/kubelet/pki/kubelet.crt
  CApath: none
* Server certificate:
*   subject: CN=ip-172-31-4-117.us-west-1.compute.internal@1514006010
*   start date: Dec 23 05:13:30 2017 GMT
*   expire date: Dec 23 05:13:30 2018 GMT
*   common name: ip-172-31-4-117.us-west-1.compute.internal@1514006010
*   issuer: CN=ip-172-31-4-117.us-west-1.compute.internal@1514006010
* NSS error -8101 (SEC_ERROR_INADEQUATE_CERT_TYPE)
* Certificate type not approved for application.
* stopped the pause stream!
* Closing connection 0
curl: (60) Certificate type not approved for application.
More details here: https://curl.haxx.se/docs/sslcerts.html

***curl failed to verify the legitimacy of the server*** and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

CA certificate rejected by curl

$ openssl x509 -noout -text -in /var/lib/kubelet/pki/kubelet.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=ip-172-31-4-117.us-west-1.compute.internal@1514006010
        Validity
            Not Before: Dec 23 05:13:30 2017 GMT
            Not After : Dec 23 05:13:30 2018 GMT
        Subject: CN=ip-172-31-4-117.us-west-1.compute.internal@1514006010
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d5:48:65:86:4e:ec:08:a1:b1:26:4b:da:7c:e0:
                    d9:d0:16:96:93:9e:c0:f3:78:cb:27:a9:e1:99:d2:
                    10:73:70:e5:1e:ee:03:1a:55:51:29:c6:2e:62:71:
                    d9:c2:72:19:d3:36:41:9b:ef:74:ac:20:97:25:1b:
                    63:55:96:07:4d:02:01:c9:44:7d:f9:63:2b:50:98:
                    2a:fb:b7:03:0d:96:6d:6a:36:9d:93:ad:2c:6a:87:
                    7d:b8:aa:22:ca:f2:c4:a6:90:24:2b:4c:94:d1:4a:
                    3c:0d:c5:fa:48:fb:e5:82:30:17:f9:67:3a:1d:9b:
                    85:7a:bc:e9:e9:79:48:0e:53:41:fc:64:3a:c3:c1:
                    7e:ae:51:23:17:8e:db:1e:4c:99:56:a4:77:ad:74:
                    64:64:ab:a7:84:02:40:ec:c8:b1:51:2b:b3:80:7e:
                    b2:51:68:5c:d2:40:9d:f3:54:b9:76:2d:47:ea:f4:
                    51:c6:03:e9:c4:63:5c:5a:a7:7e:9a:97:89:45:99:
                    e8:a0:9b:5d:1d:15:94:f9:c9:2a:a4:19:a2:07:25:
                    2b:e6:0e:50:63:c0:6e:f9:a0:a7:ce:4a:ca:97:17:
                    64:2f:8a:e2:39:d5:e2:c9:c7:c4:53:f1:6e:14:22:
                    ca:02:cb:8a:0c:47:68:31:f2:0b:20:2c:a3:a5:5f:
                    cd:95
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Alternative Name:
                DNS:ip-172-31-4-117.us-west-1.compute.internal
    Signature Algorithm: sha256WithRSAEncryption
         bc:84:b2:5c:c1:a5:52:b7:03:ae:9c:53:47:4b:ca:8b:4a:90:
         7f:41:0f:09:ff:77:5e:cc:7c:2c:0c:bc:37:71:c9:22:4e:7f:
         eb:9f:a9:f8:04:1d:8d:39:67:52:46:9c:3b:dc:d8:1f:b0:00:
         64:ed:2f:bf:8f:4c:8c:f2:6b:96:ec:99:66:19:39:1d:11:77:
         52:6b:a8:f4:88:e1:ad:6b:61:af:bd:c0:fc:f7:c2:37:a2:c2:
         7f:cc:de:98:a4:61:25:e2:78:b2:ab:94:31:0d:8f:2f:92:7b:
         4a:4f:5b:1c:c2:e8:bd:43:cb:78:0e:f2:4b:b9:a5:54:0c:46:
         0f:b0:92:f8:3c:57:08:6a:df:a4:cd:78:63:23:2f:13:12:7f:
         89:7f:3d:c0:dd:c7:33:8d:55:76:10:38:47:2b:16:ce:d0:93:
         c4:9e:28:42:1e:2b:f4:78:15:dd:89:1e:67:a5:a1:a1:13:30:
         9a:2f:60:82:71:db:29:47:af:e7:61:71:1c:d6:72:27:61:17:
         e1:31:aa:ee:84:0d:53:f8:66:18:49:34:5d:fb:50:fb:4f:c7:
         b5:a1:8e:34:86:81:25:ad:31:d4:5c:9e:da:8d:08:85:a9:91:
         c6:f8:83:c7:23:57:11:04:dc:90:5a:c9:5a:bf:dd:3c:9c:6a:
         17:d8:d0:1f

Research

The kubernetes GitHub says:

• Change self signed certificates to not include extended key usage #311
• Switch to wget for integration apiserver checks

The NSS encryption library does not allow a CA to be used with the extended key usage present, at least in the way we are currently doing so. The generated self signed certificates extension section looks like:

...
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment, Certificate Sign
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Alternative Name:
                DNS:localhost, IP Address:127.0.0.1, IP Address:127.0.0.1 

RFC 3218

X509v3 Key Usage: critical
    Digital Signature, Key Encipherment, Certificate Sign

and

X509v3 Basic Constraints: critical
    CA:TRUE

should be satisfying RFC 3218 4.2.1.3 Key Usage.

The key usage extension defines the purpose (e.g., encipherment,
signature, certificate signing) of the key contained in the
certificate. The usage restriction might be employed when a key that
could be used for more than one operation is to be restricted.
…

The keyCertSign bit is asserted when the subject public key is
used for verifying a signature on public key certificates. If the
keyCertSign bit is asserted, then the cA bit in the basic
constraints extension (section 4.2.1.10) MUST also be asserted.

X509v3 Extended Key Usage:
    TLS Web Server Authentication

should be satisfying RFC 3218 4.2.1.13 Extended Key Usage

If the extension is present, then the certificate MUST only be used
for one of the purposes indicated. If multiple purposes are
indicated the application need not recognize all purposes indicated,
as long as the intended purpose is present. Certificate using
applications MAY require that a particular purpose be indicated in
order for the certificate to be acceptable to that application.

If a CA includes extended key usages to satisfy such applications,
but does not wish to restrict usages of the key, the CA can include
the special keyPurposeID anyExtendedKeyUsage. If the
anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT
be critical.

If a certificate contains both a key usage extension and an extended
key usage extension, then both extensions MUST be processed
independently and the certificate MUST only be used for a purpose
consistent with both extensions. If there is no purpose consistent
with both extensions, then the certificate MUST NOT be used for any
purpose.

…

id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
— TLS WWW server authentication
— Key usage bits that may be consistent: digitalSignature,
— keyEncipherment or keyAgreement

Root certificate key usage (non-self-signed end entity) suggests it would be OK not to have cRLSign/CRL signing flag.

Since a CA is supposed to issue certificate and CRL, it should have, on a general basis, the keyCertSign and cRLSign flags. These two flags are sufficient. If the CA does not intend to sign its own CRL, then it may omit the cRLSign flag;

Question

So why curl thinks the CA certificate does not assert a required usage?

Related

• Key usage extensions and extended key usage
• Missing ‘Key Usage’ on a CA certificate: can sign certificates?
• SSL Certs issued with PKI backend don’t work with firefox: sec_error_inadequate_cert_type #987
• curl: (60) Certificate type not approved for application where wget works
• GitHub — Network Security Services
• curl source code control

Howdy,
I run a Private Certificate Authority for my personal use and just to learn about SSL Certs. However, with the current build of FireFox I’m on ( 31 ) I can no longer visit sites I’ve secured with SSL Certs signed by this certificate authority, even though these SSL certs work just perfectly fine in Chrome and Internet Explorer. I keep getting a «sec_error_inadequate_cert_type» error. I can only assume that the certs I’ve been issuing are incorrect in some way, but the error is so vague and the error page doesn’t specify more.
I only discovered this when I realized some of my SSL certs had expired, and I went to re-issue them.
One of the certs that hasn’t expired yet but is experiencing problems can be found here:
* https://forums.silicateillusion.org
One of the Certs I’ve tried re-issuing, matching fields included as closely as I can to a Google SSL cert that I looked up is here:
* https://phpmyadmin.endofevolution.com
These certificates were generated using the application called SimpleAuthority, found here: http://simpleauthority.com/
A Site like Networking4All.com seems to believe the Certs are valid, excepting the CA that is Self Signed: http://www.networking4all.com/en/support/tools/site+check/report/?fqdn=phpmyadmin.endofevolution.com&protocol=https
Interestingly enough, using a different site like SSLShopper shows an error similar to FF31: http://www.sslshopper.com/ssl-checker.html#hostname=https://phpmyadmin.endofevolution.com
The certs are running on an Apache Web server: Apache/2.2.21 (Win32) mod_ssl/2.2.21 OpenSSL/1.0.0e PHP/5.3.10
The CA Cert is in FireFox’s store as trusted.
If needed, I can provide certs.