How can I persist values of KeyUsage and BasicConstraints in the ECDSA based certificates from LetsEncrypt? - lets-encrypt

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/

Related

Custom signed efi getting invalid. "Certificate type not approved for application."

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.

How to set up the issuer of the certificate is Microsoft testing root certificate authority?

I use makecert.exe to get a KM_test1.cer, and then run signtool sign <myfile.dll> to sign myfile.dll. but it failed when I run signtool verify <myfile.dll>.
C:\Windows\System32>>makecert.exe -r -pe -ss PrivateCertStore -n CN=KM_test1 KM_test1.cer
Successed
C:\Windows\System32>>certmgr.msc
// drop this.cer file to Personal store
C:\Windows\System32>>signtool sign /fd sha1 "myfile.dll"
Done Adding Additional Store
Successfully signed: myfile.dll
C:\Windows\System32>signtool verify /debug "myfile.dll"
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 32AEC1684BEACFDA35755E7342ADDA4B5196BF40
Signing Certificate Chain:
Issued to: KM_test1
Issued by: KM_test1
Expires: Sun Jan 01 08:59:59 2040
SHA1 hash: xxxxxxxxxxxxxxxxCC62D5F31D39188206765D27
File is not timestamped.
SignTool Error: A certificate chain processed, but terminated in a root
certificate which is not trusted by the trust provider.
I have a file that can pass signtool vertify "correctFile.dll" and work for my project. it prints the follow info:
C:\Windows\System32>signtool verify /debug correctFile.dll
Verifying: correctFile.dll
Signature Index: 0 (Primary Signature)
Hash of file (sha1): xxxxxxxxxxxxxxxxxxxx7445032578A8D7B6EFAC
Signing Certificate Chain:
Issued to: Microsoft Testing Root Certificate Authority 2010
Issued by: Microsoft Testing Root Certificate Authority 2010
Expires: Mon Jun 18 06:04:11 2035
SHA1 hash: xxxxxxxxxxxxxxxxxxxxxx6A76B8178FA215F344
Issued to: Microsoft Testing PCA 2010
Issued by: Microsoft Testing Root Certificate Authority 2010
Expires: Mon Jun 18 06:04:11 2035
SHA1 hash: xxxxxxxxxxxxxxxxxxxxxAFC0BE2F1D13AB21773
Issued to: Microsoft Windows Publisher
Issued by: Microsoft Testing PCA 2010
Expires: Mon Nov 28 02:21:47 2022
SHA1 hash: xxxxxxxxxxxxxxxxxxx1305E8B85AC0BA257DDDF
File is not timestamped.
Successfully verified: correctFile.dll
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
i guess the problem is located in Signing Certificate Chain. Maybe it will work if i set the issuer of certificate is Microsoft Testing Root Certificate Authority 2010. So, does anyone have an idea about this issue?

macOS SecureTransport refuses to import a certificate accepted by OpenSSL

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.

Code signing Excel Add-In makes Excel think it's tampered

We've created an Excel DNA AddInand we're getting it ready for the wild. So we want to have it signed with our organisation's code-signing certificate.
So, after receiving a pfx certificate, I installed it to my personal space and grabbed the thumbprint and used the SignFile task in our .csproj file to make signed output files on a release build.
Here is the code from the csproj file. Worth noting that there is an AfterBuild target that copies the output files to the out directory and renames them.
<Target Name="SignOutputs" AfterTargets="AfterBuild"
Condition="$(Configuration) == 'Release'">
<PropertyGroup>
<FileToSign32>$(SolutionDir)out\AddIn.xll</FileToSign32>
<FileToSign64>$(SolutionDir)out\AddIn64.xll</FileToSign64>
<CertificateThumbprint>8ccfeae0....</CertificateThumbprint>
<TimestampUrl>http://timestamp.digicert.com</TimestampUrl>
</PropertyGroup>
<SignFile CertificateThumbprint="$(CertificateThumbprint)" SigningTarget="$(FileToSign32)" TimestampUrl="$(TimestampUrl)" />
<SignFile CertificateThumbprint="$(CertificateThumbprint)" SigningTarget="$(FileToSign64)" TimestampUrl="$(TimestampUrl)" />
</Target>
This correctly signs the output files. When you look at the digital signature of the files, it's all happy and good - "This digital signature is OK", etc. The certificate has another 3 years on it, so we're definitely in date.
Running signtool verify on it returns okay as well.
signtool verify /v /pa "AddIn.xll"
Verifying: AddIn.xll
Signature Index: 0 (Primary Signature)
Hash of file (sha256): Hash here
Signing Certificate Chain:
Issued to: DigiCert Assured ID Root CA
Issued by: DigiCert Assured ID Root CA
Expires: Mon Nov 10 01:00:00 2031
SHA1 hash: Hash here
Issued to: DigiCert SHA2 Assured ID Code Signing CA
Issued by: DigiCert Assured ID Root CA
Expires: Sun Oct 22 13:00:00 2028
SHA1 hash: Hash here
Issued to: Us
Issued by: DigiCert SHA2 Assured ID Code Signing CA
Expires: Wed Oct 09 13:00:00 2019
SHA1 hash: Hash here
The signature is timestamped: Tue Oct 25 11:29:42 2016
Timestamp Verified by:
Issued to: DigiCert Assured ID Root CA
Issued by: DigiCert Assured ID Root CA
Expires: Mon Nov 10 01:00:00 2031
SHA1 hash: Hash here
Issued to: DigiCert Assured ID CA-1
Issued by: DigiCert Assured ID Root CA
Expires: Wed Nov 10 01:00:00 2021
SHA1 hash: Hash here
Issued to: DigiCert Timestamp Responder
Issued by: DigiCert Assured ID CA-1
Expires: Tue Oct 22 01:00:00 2024
SHA1 hash: Hash here
Successfully verified: AddIn.xll
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
I thought this meant it was all signed and happy. So I went ahead and ran this in Excel, and received a warning message:
Warning: The digital signature on this application add-in is invalid and cannot
be trusted. Application add-in is disabled.
Bemused, mythed and befuddled, I flailed around until I managed to stumble across Enable Trust Center logging. Then, I managed to find the Trust Center logs. For the AddIn, it has this entry.
---
Content Type: Add-in DLL
Binary: "C:\development\out\AddIn.xll"
Certificate: Us
Certificate Signature: DigiCert SHA2 Assured ID Code Signing CA
Certificate Status: Tampered
Trust Center Decision: Block Content
User Decision: Block Content
Error Code: 80096001
80096001 according to MSDN apparently maps to this message: "A system-level error occurred while verifying trust".
That doesn't give me much to go on. I can't see anything obviously wrong, but it's possible I'm missing something.
Signing with signtool in the dev command prompt yields the same result.
I've just been running in circles on Google, and I'm starting to get to the point now where the results are offering me executables to fix the corrupted system files that cause this (spoiler: they're almost certainly malware). So I think I need some guidance.
How do I sign my XLL files without having them come up as "tampered"?

Firefox says certificate is untrusted even though the certificate chain is good

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.

Resources