I'm trying to fix a failing test in the urllib3 open source Python project.
This test is called test_client_no_intermediate and tries to use a X.509 certificate called client_no_intermediate.pem. The goal is to fail with a "unknown CA" error. The test works as expected with OpenSSL: the import succeeds and the certificate is rejected.
However, on macOS with SecureTransport, the import fails with Import/Export format unsupported.. What's surprising is that it fails consistently on my machine with macOS 10.13.5 and Xcode 9.4.1 but only fails intermittently in continuous integration with macOS 10.12 and XCode 8.3.
Here is the certificate:
-----BEGIN CERTIFICATE-----
MIIC/jCCAmegAwIBAgImFhgDOYh0mJSEggRYaDQ2VjgRdyAwkXmAV2KGITVEhiJw
UmBGKBgwDQYJKoZIhvcNAQELBQAwcTELMAkGA1UEBhMCRkkxDjAMBgNVBAgMBWR1
bW15MQ4wDAYDVQQKDAVkdW1teTEOMAwGA1UECwwFZHVtbXkxETAPBgNVBAMMCFNu
YWtlT2lsMR8wHQYJKoZIhvcNAQkBFhBkdW1teUB0ZXN0LmxvY2FsMB4XDTE3MDUx
MjE4MzQyNloXDTIxMTIxOTE4MzQyNlowdzELMAkGA1UEBhMCRkkxDjAMBgNVBAgM
BWR1bW15MQ4wDAYDVQQKDAVkdW1teTEOMAwGA1UECwwFZHVtbXkxFzAVBgNVBAMM
DlNuYWtlT2lsQ2xpZW50MR8wHQYJKoZIhvcNAQkBFhBkdW1teUB0ZXN0LmxvY2Fs
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCadkbPLXPfA1bNjgL9F6+rVLs3
uZdbXemHf1oKkT4q9uruZTQCTDFvvWHq32r6G8KV7MASariSz+bIgpx1euZEOmwu
cd+ULs0HMdfqorRa3MuUtKuIzYiQvCsv788VoNKjs+NNMIexO6p6S9E36ce2trze
BCmpYmi0WofO0bSwnwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQf
Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUbe9reSw2
C72JuGVpc+/L/O2hVjwwHwYDVR0jBBgwFoAUnltsnuh2mjtqqDWk2RNSwC7njHkw
DQYJKoZIhvcNAQELBQADgYEADlJp3uMKxgS2hgCK+JZV4qsXGuZ/rcHgq5qlrfg0
i76+wwZ6fs3WQe+zNgXbJnRviM0VScSUBM8IuclyovFWLvs0Z0piELtZ7KPwrDVf
5S5ynJHnJSG+sj4N6v+tvtpGDb1S3ueLQm79MGXv9pmbaYBmUJ0YSEnrScWy90Bv
Tno=
-----END CERTIFICATE-----
OpenSSL happily decodes it:
$ openssl x509 -noout -in client_no_intermediate.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
16:18:03:39:88:74:98:94:84:82:04:58:68:34:36:56:38:11:77:20:30:91:79:80:57:62:86:21:35:44:86:22:70:52:60:46:28:18
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=FI, ST=dummy, O=dummy, OU=dummy, CN=SnakeOil/emailAddress=dummy#test.local
Validity
Not Before: May 12 18:34:26 2017 GMT
Not After : Dec 19 18:34:26 2021 GMT
Subject: C=FI, ST=dummy, O=dummy, OU=dummy, CN=SnakeOilClient/emailAddress=dummy#test.local
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:9a:76:46:cf:2d:73:df:03:56:cd:8e:02:fd:17:
af:ab:54:bb:37:b9:97:5b:5d:e9:87:7f:5a:0a:91:
3e:2a:f6:ea:ee:65:34:02:4c:31:6f:bd:61:ea:df:
6a:fa:1b:c2:95:ec:c0:12:6a:b8:92:cf:e6:c8:82:
9c:75:7a:e6:44:3a:6c:2e:71:df:94:2e:cd:07:31:
d7:ea:a2:b4:5a:dc:cb:94:b4:ab:88:cd:88:90:bc:
2b:2f:ef:cf:15:a0:d2:a3:b3:e3:4d:30:87:b1:3b:
aa:7a:4b:d1:37:e9:c7:b6:b6:bc:de:04:29:a9:62:
68:b4:5a:87:ce:d1:b4:b0:9f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
6D:EF:6B:79:2C:36:0B:BD:89:B8:65:69:73:EF:CB:FC:ED:A1:56:3C
X509v3 Authority Key Identifier:
keyid:9E:5B:6C:9E:E8:76:9A:3B:6A:A8:35:A4:D9:13:52:C0:2E:E7:8C:79
Signature Algorithm: sha256WithRSAEncryption
0e:52:69:de:e3:0a:c6:04:b6:86:00:8a:f8:96:55:e2:ab:17:
1a:e6:7f:ad:c1:e0:ab:9a:a5:ad:f8:34:8b:be:be:c3:06:7a:
7e:cd:d6:41:ef:b3:36:05:db:26:74:6f:88:cd:15:49:c4:94:
04:cf:08:b9:c9:72:a2:f1:56:2e:fb:34:67:4a:62:10:bb:59:
ec:a3:f0:ac:35:5f:e5:2e:72:9c:91:e7:25:21:be:b2:3e:0d:
ea:ff:ad:be:da:46:0d:bd:52:de:e7:8b:42:6e:fd:30:65:ef:
f6:99:9b:69:80:66:50:9d:18:48:49:eb:49:c5:b2:f7:40:6f:
4e:7a
But SecureTransport fails on this specific certificate:
$ security verify-cert -c cacert.pem
Cert Verify Result: CSSMERR_TP_NOT_TRUSTED
$ security verify-cert -c client_no_intermediate.pem
SecCertificateCreateFromData: Unknown format in import.
What is wrong in this certificate?
The only thing obviously "wrong" with the certificate is the serial number is 38 bytes long.
https://www.rfc-editor.org/rfc/rfc3280#section-4.1.2.2
Given the uniqueness requirements above, serial numbers can be
expected to contain long integers. Certificate users MUST be able to
handle serialNumber values up to 20 octets. Conformant CAs MUST NOT
use serialNumber values longer than 20 octets.
While there is also guidance that non-conformant CAs exist, it's possible that Apple put in a limit lower than 38 bytes.
That wouldn't explain intermittency, but having a certificate which doesn't look "conformant" is always asking for unreliability.
Related
I'm trying to boot an efi loader signed with my custom keys. I've already enrolled its public key in mokmanager, still it is getting blocked in uefi when secure boot is turned on. It looks like the efi is not signed properly.
[root#hp-fedora]/tmp/test# ls
DB.auth DB.crt DB.key KEK.cer KEK.esl mkkeys.sh noPK.auth PK.auth PK.crt PK.key refind_x64.efi.signed
DB.cer DB.esl KEK.auth KEK.crt KEK.key myGUID.txt noPK.esl PK.cer PK.esl refind_x64.efi
[root#hp-fedora]/tmp/test# openssl x509 -in DB.crt -out DB.cer -outform DER
[root#hp-fedora]/tmp/test# sbsign --key DB.key --cert DB.crt --output refind_x64.efi.signed refind_x64.efi
Signing Unsigned original image
[root#hp-fedora]/tmp/test# pesign --show-signature --in=refind_x64.efi.signed
---------------------------------------------
certificate address is 0x7f338a625f88
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is mykeys DB
No signer email address.
Signing time: Thu Aug 11, 2022
There were certs or crls included.
---------------------------------------------
[root#hp-fedora]/tmp/test# pesigcheck -i refind_x64.efi.signed -n 0 -c DB.cer
Searching db DB.cer
Searching db DB.cer
Certificate type not approved for application.
pesigcheck: "refind_x64.efi.signed" is invalid.
I am using mbedtls 2.16.3 .
I use mbedtls library to create two level certificate and use the certificate to set up https communication.
The root certification(also be CA) is a self-signed certificate using ECC secp256r1.
The device certification is signed by the root certificate, and the key algorithm is also ECC secp256r1.
I install the root certification in the OS system and Firefox certification manager.
Chrome will show “Certificate Unknown” after receiving the certificate(The chrome version is 86.0.4240.75)
The wireshark shows as followings:
Wireshark caption
The chrome shows as followings:
NET::ERR_CERT_INVALID
Subject: 10.9.1.67
Issuer: Web Server Root
Expires on: 2021/10/13
Current date: 2020/10/19
PEM encoded chain:
-----BEGIN CERTIFICATE-----
MIIBejCCAR6gAwIBAgISANm85JYVS9N1992FvOfHxhsAMAwGCCqGSM49BAMCBQAw
JzELMAkGA1UEBhMCQ04xGDAWBgNVBAMMD1dlYiBTZXJ2ZXIgUm9vdDAeFw0yMDEw
MTYwMTIzMTdaFw0yMTEwMTMwMjQyNDRaMCExCzAJBgNVBAYTAkNOMRIwEAYDVQQD
DAkxMC45LjEuNjcwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATdpywNJKmMvDr2
esvqe9CVhjhQDgzzUo6WhMD91CosNJhkDtkMAbexQkq/je6IQyZABxFkiDMweLWe
uJR3rTbNoy4wLDAPBgNVHREECDAGhwQKCQFDMAkGA1UdEwQCMAAwDgYDVR0PAQH/
BAQDAgOoMAwGCCqGSM49BAMCBQADSAAwRQIgPRgDnfR7NIXfUlvaUyDtsIJDUGV2
BFKf7wxElxfbKDICIQDpVu5Ty9tZznQeuch+5LV0vDqXm6EWg+Viv6w5O59QIg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIBdDCCARigAwIBAgIRfRupqU8vSJw2LfGv1LSuXwAwDAYIKoZIzj0EAwIFADAn
MQswCQYDVQQGEwJDTjEYMBYGA1UEAwwPV2ViIFNlcnZlciBSb290MB4XDTIwMTAx
NjA5MjMxNloXDTQwMTAxNjA5MjMxNlowJzELMAkGA1UEBhMCQ04xGDAWBgNVBAMM
D1dlYiBTZXJ2ZXIgUm9vdDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABMZaKSeR
hoDgIeVbNkBYY0/n7z4JD+y+bZBXuDsFzYbz4odAe2C3WxpJ7fUw6sOCs1jpy8mv
neV1sRH3KXEXqNOjIzAhMA8GA1UdEwQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgKE
MAwGCCqGSM49BAMCBQADSAAwRQIgPa8BVP5Bt2YLQ3DHEbGsg79nJbtTSAKmAPaa
5NLEIEcCIQCENcnKEdTKV0L/1c3evynH/hP97mid58trLgBRlFU3Dw==
-----END CERTIFICATE-----
But the certification works well on Firefox/Edge.
And if I change the self-signed certificate to RSA 1024, the https connection in Chrome is okay.
There is a very quick fix to this issue.
In function: mbedtls_asn1_write_algorithm_identifier of asn1write.cpp, just delete this line of code:MBEDTLS_ASN1_CHK_ADD( len, mbedtls_asn1_write_null( p, start ) );
I am trying to set up a CA and I need a root certificate for this CA. This root certificate has to be signed by a public CA and the signing algorithm has to be ECDSA with prime256v1 curve.
I am following this issue on LetsEncryp forum. However, I am using a separate utility for generating the keys and CSR. This utility helps me generate ECDSA keys and CSR successfully. Following is the CSR that's generated:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: O=MyOrg, L=Bengaluru, ST=Karnataka, C=IN, CN=mydomain.in
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
<value>
ASN1 OID: prime256v1
NIST CURVE: P-256
Attributes:
Requested Extensions:
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
Signature Algorithm: ecdsa-with-SHA256
<value>
So, basically I am getting correct values for KeyUsage and BasicConstraints in the extension.
Now, for the next step, I am using the following command from my ec2 instance:
certbot certonly -d <mydomain> --server https://acme-v02.api.letsencrypt.org/directory --csr <csr_generated_above> --cert-name <mydomain>
Using this command I'm able to get a certificate signed by LetsEncrypt along with the certificate chain. However, in the certificate that is generated, I get different values for KeyUsage and BasicConstraints:
Owner: CN=<my_domain>
Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US
Serial number: <value>
Valid from: Fri Jan 03 14:46:29 UTC 2020 until: Thu Apr 02 14:46:29 UTC 2020
Certificate fingerprints:
SHA1: <value>
SHA256: <value>
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 256-bit EC key
Version: 3
Extensions:
#1: <value>
#2: <value>
#3: <value>
#4: ObjectId: <value> Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
]
#5: <value>
#6: ObjectId: <value> Criticality=false
ExtendedKeyUsages [
serverAuth
clientAuth
]
#7: ObjectId: <value> Criticality=true
KeyUsage [
DigitalSignature
]
#8: <value>
#9: <value>
As seen above, the KeyUsage, BasicConstraints and Signature algorithm are not persisted. And the issue is my CA needs that one of the values of KeyUsage should be 'Certificate Sign'. Due to which my CA is not able to spinup.
So my question is:
Is it feasible to get a root cert for my CA from LetsEncrypt?
If yes, do we need to pass some extra flags with the cert bot command?
Or where am I getting this wrong?
I'm quite new to using public ca for the certificate generation.
LetsEncrypt does not issue anything except Domain Validated certificates. No code signing certificates, no root CA certificates, nothing else.
https://letsencrypt.org/docs/faq/
I'm tring to create certificate via Visual Studio Command Prompt to meet the following requirements :
• A valid, (not expired), X.509 signing certifi cate must be used (e-mail certifi cate).
• RSA public key (signature) algorithms using key lengths of 1024 bits (or larger).
• Message Digest Algorithm must be SHA1-RSA.
• Encryption algorithm is DES3 (triple DES).
• Key usage must include digital signature (for signing fi les) and key encipherment (for encrypting
the fi les).
• Certifi cate (Public Key Only) should be exported in the following format
» .p7c (* PKCS7 cryptographic message syntax standard certifi cate)
» .cer (DER encoded binary X.509 Certifi cate)
» .cer (Base64 encoded X.509 Certifi cate)
I have tried as :
makecert.exe -sv TestCert.pvk -n “Test Cert” -a sha1 -len 1024 -sky 2 -eku 1.6.6.9.2.8.0.3.9 TestCert.cer -r
pvk2pfx.exe -pvk TestCert.pvk -spc TestCert.cer -pfx TestCert.pfx -po Test123$
I also am reading from https://msdn.microsoft.com/en-us/library/bfsktky3(v=vs.100).aspx
but so far I have no luck. I have done someting valid one while ago but don't seem to remember how. Can someone give me some tips or example will be great.
Thanks in advance.
The algorithm is named 3DES, not DES3.
The encryption algorithm can be applied at the stage of writing the private key to the disk in some format (like PEM or PFX). It's not a part of the certificate. This is why you can't find any option to do this.
HTTPS for https://www.bigfont.ca is working in Chrome, Internet Explorer, and Safari but not in Firefox. It also passes all the tests at this SSL Checkers. Firefox says:
An error occurred during a connection to www.bigfont.ca.
Peer's certificate has been marked as not trusted by the user.
(Error code: sec_error_untrusted_cert)
This is a known situation with Firefox. We looked at the StartSSL FAQ and the advice is:
You must add the intermediate CA certificate to your installation.
We are using SmartSSL and OpenSSL to create an SSL Certificate. So, we added the intermediate CA certificate by following Troy Hunt's tutorial and ran this command to create the PFX.
OpenSSL> pkcs12 -export -in bigfont.ca.crt -inkey bigfont.ca-encrypted.key
-certfile sub.class1.server.ca.pem -out bigfont.ca.pfx -password pass:my-password
We uploaded the resultant bigfont.ca.pfx file to at the Azure Website's Config page.
To test further, we ran openssl s_client -servername www.bigfont.ca -connect www.bigfont.ca:443 -showcerts. The results show that the certificate chain is working well.
depth=1 C = IL,
O = StartCom Ltd.,
OU = Secure Digital Certificate Signing,
CN = StartCom Class 1 Primary Intermediate Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:
/description=T8eg9X1a04Scp3hM
/C=CA
/CN=www.bigfont.ca
/emailAddress=shaunluttin#bigfont.ca
i:
/C=IL
/O=StartCom Ltd.
/OU=Secure Digital Certificate Signing
/CN=StartCom Class 1 Primary Intermediate Server CA
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
1 s:
/C=IL
/O=StartCom Ltd.
/OU=Secure Digital Certificate Signing
/CN=StartCom Class 1 Primary Intermediate Server CA
i:
/C=IL
/O=StartCom Ltd.
/OU=Secure Digital Certificate Signing
/CN=StartCom Certification Authority
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
---
Server certificate
subject=
/description=T8eg9X1a04Scp3hM
/C=CA
/CN=www.bigfont.ca
/emailAddress=shaunluttin#bigfont.ca
issuer=
/C=IL
/O=StartCom Ltd.
/OU=Secure Digital Certificate Signing
/CN=StartCom Class 1 Primary Intermediate Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3369 bytes and written 547 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-SHA
Session-ID: 6E1F00009...FDD7B7BF7B7
Session-ID-ctx:
Master-Key: 2FA3C020A506198C1319081F9E023D35...5AEB01985323AADCF9
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1413947020
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
read:errno=10054
If the chain is working, why does Firefox complain?
Solution
Reset Firefox to its default state.
Firefox
Help
Troubleshooting Information
Reset Firefox
Details
The problem turned out to be related to the cert8.db file that stores the Firefox certificates. Find it here:
Firefox
Help
Troubleshooting Information
Application Basics
Profile Folder
Show Folder
The problem was probably that we messed with Firefox's Authorities Certificate for StartCom. We probably did this while muddling thru the process of restoring our StartSSL Client Authentication certificate.
Your Certificates (Client Authentication)
Authorities
We probably accidentally messed with these, thereby making Firefox not trust StartCom.
It wasn't relevant when the question was asked, but it is worth mentioning now.
A lot of browsers has stopped trusting StartCom.
The previous answers might still help with similar problems for other issuers than StartCom.
But if you are still using StartCom, you might want to switch to https://letsencrypt.org
Deleting the CA certificate and importing it again did the trick for me.