Hello all and thanks for your time reading this.
I need to verify certificates issued by my own CA, for which I have a
certificate. How can I do the equivalent to openssl's
openssl verify -CAfile
in Ruby code? The RDoc for OpenSSL is not very helpful in this regard.
I've tried:
require 'openssl'
ca = OpenSSL::X509::Certificate.new(File.read('ca-cert.pem'))
lic = OpenSSL::X509::Certificate.new(File.read('cert.pem'))
puts lic.verify( ca )
but I get:
test.rb:7:in `verify': wrong argument (OpenSSL::X509::Certificate)!
(Expected kind of OpenSSL::PKey::PKey) (TypeError)
from test.rb:7
I can't even find "verify" in the OpenSSL Rdoc at
http://www.ruby-doc.org/stdlib/libdoc/openssl/rdoc/index.html.
Any help is appreciated. Thanks again!
You need to validate with
lic.verify(ca.public_key)
in addition before that you can verify certificate issuer with
lic.issuer.to_s == ca.subject.to_s
I used one Japanese help page to get the list of available methods :)
lic.verify() only verify the key from the certificate that signed lic. Ccommercial root CAs do not sign end user certificates directly. Usually there is one or 2 intermediate signing certificates involved.
So if CA -> signer -> user cert then
lic.verify( signer.public_key) and signer.verify( CA.public_key) will return true but lic.verify( CA.public_key ) will return false.
Related
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.
In order to get Microsoft PlayReady Server Agreement I need to sign WMLA.ocx file with Extended Validation Code Signing Certificate and send it back to Microsoft.
I've obtained Extended Validation Code Signing Certificate pack from Thawte, it contains:
1. Code Signing certificate itself
2. CA
3. PKCS7 certificate
Put Code Signing certificate itself to separate file with .cer extension.
I've downloaded Microsoft Code Signing pack from http://go.microsoft.com/fwlink/?LinkID=148072 contains:
a. Signcode.exe
b. WMLA.ocx
c. WMLA Instructions for EV Cert OCX v10 17 16.pdf
Following instructions (option 3) from http://msdn2.microsoft.com/en-us/library/ms537364.aspx we've tried to sign .ocx file using Signcode.exe and Code Signing certificate itself in .cer file.
Enter following command in command line:
C:\Users\User123\WMLA>signcode.exe -c ev.cer WMLA.ocx
And got error:
Error: There is no valid certificate in the my cert store
Error: Signing Failed. Result = 8009200c, (-2146885620)
Certificate is valid, but I'm not sure about signcode.exe options and putting certificate in separate .cer file?
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.
In theory it should be possible to validate the signature of a piece of data if in possesion of the public key, signature and data that was signed and the hash algorithm is known.
I have all these components in binary format. Does anybody have an idea about the easiest way to validate this signature? OpenSSL? Python? An example would be great. Can it be done without writing code?
Here's how you can do it in Ruby.
require 'openssl'
signature = File.read('/path/to/sig.der')
data = File.read('/path/to/data')
pub_key = File.read('/path/to/ecdsa_pub_key')
key = OpenSSL::PKey::EC.new(pub_key)
if key.dsa_verify_asn1(data, signature) == true
puts 'verified'
end
This code requires that the OpenSSL linked against Ruby be compiled with elliptic curve support. (Red Hat flavored distributions of Linux do not satisfy this requirement)
If you're curious: dsa_verify_asn1 uses the ECSDA_verify function in the OpenSSL API.
You can use openssl to sign a message with a ECDSA signature, and then you can use openssl to verify the signature:
To sign a message (using SHA256 hashing, given the message and the signer's EC private key):
openssl dgst -sha256 -sign ec-privatekey.pem message.txt > signature.der
Then, to verify the signature (again using SHA256 hashing, given the message, the signer's EC public key, and the signature created above):
openssl dgst -sha256 -verify ec-publickey.pem -signature signature.der message.txt
I've created a Firefox plugin, a Win32-native code DLL - using Firebreath. I'm working on Windows 7/x64, and targeting Windows only. The plugin itself is working well, but I'm really stuck getting a correctly signed XPI. If I don't sign my XPI, it's accepted and installed by FF 3.6 thru 10 (beta). Of course, during the install it lists the publisher as (Author not verified). So, I spent a week debugging the signing process... but FF 9 and 10 still say (Author not verified)! FF 3.6 rejects the signed XPI as invalid.
How do I troubleshoot this??
Just to repeat: I sign the xpi without error, and the resulting XPI installs successfully on FF 9 and 10, but FF still says (Author not verified).
Here's the batch code I use to sign the XPI:
echo * clean out old signing folder and xpi
if exist package rmdir /S /Q package
if exist %package%.xpi del %package%.xpi
echo * copy in files for package
md package
xcopy ..\*.rdf package
md package\plugins
xcopy ..\build\bin\Plugin\Debug\*.dll package\plugins
echo * clean out certificate database
del *.db
echo * import our signing certificate
pk12util -d . -i %keyfile% -K %pwd% -w keypass.txt
echo * adjust trust on base, intermediate and root cert
certutil -M -d . -n "VeriSign" -t "c,c,C"
certutil -M -d . -n "VeriSign Class 3 Code Signing 2010 CA - VeriSign, Inc." -t "TC,TC,TC"
certutil -M -d . -n "%certname%" -t "u,u,Cu"
certutil -L -d .
echo * create signed package
signtool -d . -X -Z %package%.xpi -k "%certname%" -p %pwd% package
I work for Mozilla, but this isn't an authoritative answer, just what I've gathered asking around:
So, essentially, each certificate authority has three trust bits Mozilla might grant it: they might trust it to sign websites, and/or mail, and/or code. Your certificate is from a certificate authority that Mozilla doesn't trust to sign code. (This is why going and manually setting the bit in your preferences makes it workâfor you.)
I'm told so few people try to use binary code in xpi's that Mozilla doesn't really have an organized way to find out which authorities can be used for what. However, you can check out this list: look at the "Code Trust Bit":
https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
For example (picked completely at random), ComSign Secured CA has the "Websites" and "Code" trust bits set.
I gather that Mozilla publicly discusses what rights to grant to each CA, and re-evaluates each CA periodically:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Basically your signature needs to include full certificate chain up to the trusted VeriSign root certificate, bypassing the "VeriSign Class 3 Public Primary Certification Authority - G5" with unknown trust in mozilla (bug 602107), as by default the chain ends too soon.
Your XPI is currently signed with your certificate, with no further certificate chain included, relying that the user's browser will trust the issuer of your certificate immediately. You can examine this with Mozilla's jarsigner tool (see Mozilla NSS tools):
Tools\nss-3.11>jarsigner -verify -verbose -certs my-old.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
(showing just the output for the 1st file)
You need to include a few more certificates to complete the chain to a certificate that is by default explicitly trusted in the end user's browser. In the end it should look like this:
jarsigner -verify -verbose -certs my-newly-signed.xpi
2057 Thu Sep 15 15:17:44 CEST 2011 META-INF/zigbert.rsa
sm 87 Thu Sep 15 15:17:44 CEST 2011 chrome.manifest
X.509, CN=Company Name inc., OU=General, OU=Digital ID Class 3 - Microsoft Software Validation v2, O=Company Name inc., L=City, ST=State, C=XX
[certificate will expire on 26.4.13 0:59]
X.509, CN=VeriSign Class 3 Code Signing 2010 CA, OU=Terms of use at https://www.verisign.com/rpa (c)10, OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.2.10 1:00 to 8.2.20 0:59]
[KeyUsage extension does not support code signing]
X.509, CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
[certificate is valid from 8.11.06 1:00 to 8.11.21 0:59]
[KeyUsage extension does not support code signing]
X.509, OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
[certificate is valid from 23.5.06 19:01 to 23.5.16 19:11]
To achieve this you need to:
remove the not-explicitly-trusted VeriSing's built-in certificates from the certificate database with Mozilla's certutil tool
Build the certificate trust chain of your certificate all the way up to Microsoft's "Class 3 Public Primary Certification Authority".
sign the xpi (this time full certificates chain will be included in the signature)
verify the xpi with jarsigner as described above
test the xpi in Firefox - you should not see "Author not verified" anymore.
Caveats:
Trust bits in the built-in Firefox certificate store are actually 3-state (trusted, untrusted and unknown), despite only being shown as 2-state checkbox in the FF GUI (checked=trusted, unchecked=untrusted OR unknown). By default trust is unknown, which enables you to bypass the VeriSign's certificate as described. If you ever enabled trust via FF's checkboxes it will still work, but if you uncheck the trust checkbox the trust will be set to untrusted, which will prevent bypassing that certificate in the chain. The easiest (only?) way to reset this back to initial unknown is to delete your firefox profile.
After Mozilla eventually enables the code-signing trust bit (see the bug above) you will still need to sign like this if you want to support older versions of Firefox.
Hope it helps!