I've got an email with a signature which I'm trying to verify.
I am using openssl
openssl smime -inform SMIME -CAfile all.pem -verify -in signed.eml
to check, which gives errors:
4144:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:142:
4144:error:0D068066:asn1 encoding routines:ASN1_CHECK_TLEN:bad object header:tasn_dec.c:1302:
4144:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:379:Type=X509_SIG
4144:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature failure:pk7_doit.c:978:
4144:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:pk7_smime.c:312:
After googling around for some time, this first seemed to be an error with the asn.1 structure. But running openssl asn1parse -i -in sig.txt (sig.txt being only the signature from signed.eml from before) gives no errors and shows the ASN.1 tree (IMHO) nicely.
And as a sidenote: the email is shown as successfully verified in MS Outlook 2010.
Any ideas what could be wrong with the signature or which pecularities of openssl I'm hitting here? Any other tools besides openssl to check the signature (to rule out an openssl problem)?
Ok, so with help from the openssl mailing list:
It is an error with the asn.1 structure. The signature was malformed. That wouldn't cause problems with asn1parse but would when OpenSSL tried to verify it.
It didn't have a proper DigestInfo structure but just the raw SHA1 hash, which violates the RSA scheme mentioned in the PKCS#1 specification.
Outlook (and other clients) seem to tolerate the raw form, whereas openssl (and Thunderbird and other clients) don't.
Related
I am new to learning about certificates & their use in cybersecurity. I was experimenting around with my browser's certificate issued by GTS which is google trust services.
Now, I am confused about what the signature algorithm field means. I tried to google search this and found that the signature algorithm refers to the algorithm used to sign the certificate. If that is the case, I don't understand why I see 3 different signature algorithm fields in my cert. Also, 2 of them have a key size associated with them while the first field does now.
The first signature algorithm is under the category of "Issuer" so I thought maybe this is the algorithm being used to sign the cert. The second & third fields, shown in the second image, are under the category of public key. So what are they being used to sign?
Also, I don't see any key associated with the first signature algorithm, so I am a bit confused with this. Any help is much appreciated! Thank you!
Meta: this is not a programming issue, but I can't fit this in a comment. I am not voting to close because it is inappropriate to do so after answering, but if I am notified the question is closed I will delete (or I authorize a mod to do so) to ensure Q can be deleted or roombad.
I don't know what program you are using to get that decode, or if you have modified it beyond the black-outs, but it appears to be seriously misleading. Here is a better decode from OpenSSL, which follows the ASN.1 structure, with <<# marks added by me:
(redacted)>openssl s_client -connect www.google.com:443 <NUL 2>NUL | openssl x509 -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
45:48:e6:58:30:39:c0:ad:0a:00:00:00:00:ff:65:fa
Signature Algorithm: sha256WithRSAEncryption <<#1A
Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3
Validity
Not Before: Sep 13 04:06:57 2021 GMT
Not After : Nov 20 04:06:56 2021 GMT
Subject: CN = www.google.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d7:27:92:c3:bb:e0:95:f4:20:46:a4:1a:5f:96:
78:a7:58:9d:cb:7c:2a:9c:7c:cb:2d:be:30:e9:c1:
71:80:11:da:c3:57:c4:c1:74:5c:a6:26:64:c3:49:
53:7c:44:19:f2:b3:c4:b3:5f:fc:90:30:b3:d4:31:
d1:16:09:b2:97:44:43:99:d6:13:19:20:ef:92:9e:
6e:41:44:56:32:c8:1c:5b:54:48:38:6b:5d:c5:00:
a4:62:be:7e:51:76:26:f6:5b:9c:e0:ed:b3:b8:dd:
16:eb:c6:9d:fc:b6:16:c0:60:1a:84:d8:b1:a5:d1:
5d:1f:35:eb:40:08:f0:2b:a1:a8:e8:d0:93:8f:85:
c6:25:a3:63:d0:d8:09:2e:fa:d2:6f:12:73:4e:aa:
ad:6f:c6:cb:b0:24:b4:65:e3:e3:fd:03:f9:d4:64:
07:2a:4b:6b:df:6b:ae:b2:90:eb:7e:57:f0:a8:3e:
08:d1:07:06:e8:04:dc:a6:bd:02:ee:07:97:1f:cf:
41:2c:8a:b0:15:bc:de:c9:13:b9:0a:8f:38:78:4c:
03:d1:46:36:e6:54:e4:3b:5f:eb:f4:02:14:82:09:
d9:0e:60:ea:29:b4:e3:7e:81:8d:4c:81:ee:4b:6d:
6e:a8:7f:f5:79:39:21:20:01:eb:77:4d:ea:22:d8:
15:13
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
C0:43:06:E9:20:B5:1E:51:86:CF:27:BB:3B:91:D5:0B:AE:F8:99:A6
X509v3 Authority Key Identifier:
keyid:8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27
Authority Information Access:
OCSP - URI:http://ocsp.pki.goog/gts1c3
CA Issuers - URI:http://pki.goog/repo/certs/gts1c3.der
X509v3 Subject Alternative Name:
DNS:www.google.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.11129.2.5.3
X509v3 CRL Distribution Points:
Full Name:
URI:http://crls.pki.goog/gts1c3/QqFxbi9M48c.crl
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 7D:3E:F2:F8:8F:FF:88:55:68:24:C2:C0:CA:9E:52:89:
79:2B:C5:0E:78:09:7F:2E:6A:97:68:99:7E:22:F0:D7
Timestamp : Sep 13 05:06:59.644 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#2
30:45:02:21:00:84:00:48:E0:6F:E9:0F:D7:AF:A6:67:
22:C8:D3:D3:A8:E4:FB:38:11:3E:5B:C2:EF:AC:E2:54:
7A:94:AC:1A:47:02:20:1E:84:FB:69:49:C2:1B:2E:0B:
84:8C:AD:CA:13:FF:97:19:3C:57:8A:0A:AC:23:DD:61:
C2:AB:7F:07:46:45:65
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 94:20:BC:1E:8E:D5:8D:6C:88:73:1F:82:8B:22:2C:0D:
D1:DA:4D:5E:6C:4F:94:3D:61:DB:4E:2F:58:4D:A2:C2
Timestamp : Sep 13 05:06:59.161 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256 <<#3
30:45:02:21:00:D5:16:13:47:CE:39:C6:60:AF:11:24:
61:A3:D3:B6:50:BF:32:01:0D:6F:5F:5F:2E:37:E4:F8:
1E:60:9E:70:E6:02:20:09:6A:39:F4:15:FC:36:6C:5F:
9B:C7:E1:B5:48:64:7F:BC:FD:36:6E:1D:7B:E5:74:6A:
55:B0:6E:0F:AF:CF:FF
Signature Algorithm: sha256WithRSAEncryption <<#1B
3a:11:f4:ac:db:fe:63:eb:40:ae:09:4e:d2:3a:89:90:37:c2:
bd:f5:bf:8e:69:7b:48:4e:33:6a:35:46:35:50:bc:94:2e:c3:
87:b4:66:e4:d6:bd:2f:98:99:d4:ba:0f:56:04:de:20:44:86:
61:35:50:3f:66:95:fc:4a:2a:69:b7:3b:0c:70:0f:17:cc:60:
a4:fe:1d:b3:f8:90:0c:b9:fa:3d:69:d0:2f:a9:15:91:cd:89:
bb:92:7d:f5:c6:7f:2f:b8:89:0a:95:f3:71:93:1c:52:77:22:
e8:af:54:f1:b2:0f:9c:4f:9b:28:59:c4:de:ed:63:0f:7b:06:
69:ac:af:5d:bd:1c:52:ca:67:3a:db:52:10:f3:16:55:20:dd:
db:4c:e7:93:e5:d1:56:d1:1f:07:12:0c:da:8c:df:c8:d7:91:
98:5c:c2:f7:f4:dc:ff:66:6b:35:95:f8:b9:cc:cd:1d:0b:cf:
d1:99:5e:ce:1a:d9:97:f3:c5:85:65:e0:17:b9:88:c6:1e:5f:
51:01:97:21:4e:49:6b:a6:ed:3d:df:8d:95:b5:be:54:5a:e4:
58:0d:4c:50:64:5f:47:91:48:45:d4:2b:37:50:bf:d5:fb:cd:
54:f3:c5:a2:72:38:fd:44:da:f9:6f:6a:2a:45:2c:ac:c5:a5:
37:3f:e8:fe
#1A and #1B are the algorithm of the signature on the cert by the issuer, which is in the block following #1B. Yes, there are two copies of this AlgorithmIdentifier in the ASN.1 structure, at the places shown, because X.509 was designed back in the 1980s and people then were concerned about algorithm substitution attacks based on experience with symmetric/secret-key systems, which turned out not to be a significant problem for asymmetric/public-key systems. It is SHA256withRSA because the issuing CA, GTS CA 1C3, uses an RSA (2048-bit) key. Edit: found crossdupes https://security.stackexchange.com/questions/24788/signaturealgorithm-vs-tbscertificate-signature and https://security.stackexchange.com/questions/114746/why-is-the-signature-algorithm-listed-twice-in-an-x509-certificate .
#2 and #3 are the algorithms for signatures on the two Signed Certificate Timestamps (SCTs) embedded in the certificate to support Certificate Transparency. You can see each one is part of an indented block under a heading Signed Certificate Timestamp:. The SCTs are created and signed by various transparency log systems, identified by their logid, and the two log systems GTS CA 1C3 chose to use happen to both have used ecdsa-with-sha256 signatures with P-256 keys. (We can directly see only that the R,S values are 256 bits corresponding to some curve group with a 256-bit order, but RFC6962 confirms that the only acceptable ECDSA curve is P-256.)
Aside: I don't understand why you thought it necessary to black-out some information from a certificate that everyone in the world can easily get and look at. The entire purpose of a certificate (at least an Internet server certificate) is to be publicly known to everybody.
I received a new keystore .jks file for ssl connection to replace an old, but working, .jks keystore file, but I got "unexpected handshake message: serve_hello" error. I was told to make sure the keystore contains a client cert, so I used keytool to export its cert to a pem file, then use openssl to check the purpose. The result shows
Certificate purposes:
SSL client : No
SSL client CA : No
SSL server : Yes
SSL server CA : No
...
However when I applied the same process to check the old but working jks file I got the same result. Wonder if this is the right way to verify the certificate? And how to troubleshooting this handshake error with the new jks file?
Thanks!
The extended key usage extension contains OIDs which define the purpose:
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement
https://datatracker.ietf.org/doc/html/rfc5280 Page 44
See: https://oidref.com/1.3.6.1.5.5.7.3.1 and https://oidref.com/1.3.6.1.5.5.7.3.2
When opening a certificate on Windows you can see the extension here:
I have moved a PHP script to another server, and now fail to login to an IMAP (TLS) postbox:
TLS/SSL failure for mail.servername.de: SSL negotiation failed
It seems that the problem is caused by OpenSSL, because when I try to connect to the Mailserver from both servers, I get a connection in one case (the mailserver asking for input), but none in the other (the connection is closed, I am back to bash):
openssl s_client -crlf -connect mail.servername.de:993
The most obvious difference is here:
verify return:1
---
<snip>
-----END CERTIFICATE-----
subject=/CN=mail.servername.de
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 3398 bytes and written 483 bytes
Verification: OK
---
New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
And on th other server (where no connection is made)
verify return:1
depth=0 CN = mail.servername.de
verify return:1
140410888582464:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small:../ssl/statem/statem_clnt.c:2149:
---
<snip>
-----END CERTIFICATE-----
subject=CN = mail.servername.de
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3167 bytes and written 318 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Server public key is 2048 bit
On the mailserver dovecot is configured not to accept non-encrypted connections. But, I assume it already fails due to dh key too small, which seems to relate to cipher negotiation.
Now I simply fail to put the things together... Why does the SSL connection work from one server, but not from the other?
As I own the "remote end" myself, I was able to increase security. The solution is simple, and may be relevant for others as well ...
The dovecot version is 2.2.x, which is of some relevance for the DH parmaters (see Dovecot SSL configuration). In the configuration file /etc/dovecot/conf.d/10-ssl.conf you can simply add this line:
ssl_dh_parameters_length = 2048
And eventually, it may be necessary to add this here to the main configuration file /etc/dovecot/dovecot.conf at the end:
!include conf.d/*.conf
Finally, it is important not to reload, but to restart dovecot.
systemctl restart dovecot
And suddently, the weight, troubles, and frustration of several hours is gone. Great...
Further to the above, there's a change from dovecot 2.3.
ssl_dh_parameters_length is now not used, and ssl_dh must be used instead, to point to a file generated using
openssl dhparam 4096 > dh.pem
see https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/ and scroll down to SSL Security Settings. That was the only change I had to make following the upgrade to get it to work properly again. I put the dh.pem file in /etc/dovecot, so my line in 10-ssh.conf is
ssl_dh=</etc/dovecot/dh.pem
TL;DR: your new host has a newer version of OpenSSL probably with higher security settings which prohibit connecting to the host for reasons explained below.
"dh key too small" comes from OpenSSL and because of too low security.
Things changed, and for example in newest Debian versions and with OpenSSL 1.1.1 (and I guess it is similar for newer versions), the security was enhanced.
The best and simplest explanation I have found is on Debian wiki at https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1
which says:
In Debian the defaults are set to more secure values by default. This
is done in the /etc/ssl/openssl.cnf config file. At the end of the
file there is:
[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT#SECLEVEL=2
This can results in errors such as:
dh key too small
ee key too small
ca md too weak
Now the possible solutions in descending order of preference:
ask the remote end to generate better "DH" values ("Server Temp Key: DH, 1024 bits"); the best explanations are at https://weakdh.org/sysadmin.html; note specifically the "Administrators should use 2048-bit or stronger Diffie-Hellman groups with "safe" primes."
configure your end specifically for this connnection to not use the OS default and lower your settings; it should be enough to set ciphers to "DEFAULT#SECLEVEL=1" in the code that does the connection
(really, really, really not recommended) change the value of SECLEVEL from 2 to 1 in the global configuration file on your end. But this impacts all connections from your host not just this one so you are lowering the global security of your system just because of one low level of security from one remote node.
I am using DelphiMongoDB from Grijjy (DelphiMongoDB) which is working pretty cool so far. But I can't find any functions to authenticate against a MongoDB. Did anybody getting this work or figured out how to do it?
Thanks and best regards
Update: The most up to date version of the Grijjy driver now supports TLS, X.509 client certificate authentication, SCRAM SHA-1 and SHA-256 authentication. We have also tested it against MongoDB Atlas instance at Azure.
Here is a simple example of how to use the authentication.
var
Settings: TgoMongoClientSettings;
Client: IgoMongoClient;
Database: IgoMongoDatabase;
Collection: IgoMongoCollection;
Doc: TgoBsonDocument;
begin
Settings := TgoMongoClientSettings.Create;
Settings.Secure := True;
Settings.AuthMechanism := TgoMongoAuthMechanism.SCRAM_SHA_1;
Settings.AuthDatabase := 'admin';
Settings.Username := 'username';
Settings.Password := 'password';
//Settings.QueryFlags := [TgoMongoQueryFlag.SlaveOk];
Client := TgoMongoClient.Create('my.mongodb.server.com', 27017, Settings);
Database := Client.GetDatabase('mydatabase');
Collection := Database.GetCollection('mycollection');
for Doc in Collection.Find() do
Writeln(Doc.ToJson(TgoJsonWriterSettings.Pretty));
end;
Legacy: Yes, the published Grijjy driver does not support authentication, but we have tested it internally and may add this ability in the near future to Github. You are also welcome to make a pull request if you want to adapt the following changes:
MongoDB currently supports 2 types of authentication, SCRAM and x.509 Certificate Authentication. Internally we have tested the x.509 Certificate Authentication, but the current driver on Github does not reflect this ability. We have not experimented with SCRAM yet.
To make it work with the MongoDB driver we published on Github, you may have to make a couple of changes.
You need to create a self-signed CA and certificate for your MongoDB server.
You need to configure your MongoDB server to use certs.
You need to create a self-signed certificate for your MongoDB client or clients. You can use the same cert for all clients.
You need to enable SSL/TLS connections and use your client certificate with the MongoDB driver.
1 To create all the certificates, you need an existing CA or create a self-signed CA. You can use the openssl.exe binary to do most of this:
Create root certificate authority (ca.pem and privkey.pem):
openssl req -out ca.pem -new -x509 -days 3650 -subj "/C=US/ST=California/O=Company/CN=root/emailAddress=root#domain.com"
To create a self-signed certificate for your MongoDB server (server.pem):
openssl genrsa -out server.key 2048
openssl req -key server.key -new -out server.req -subj "/C=US/ST=California/O=Company/CN=db.myserver.com/emailAddress=user#domain.com"
openssl x509 -req -in server.req -CA ca.pem -CAkey privkey.pem -CAcreateserial -out server.crt -days 3650
type server.key server.crt > server.pem
openssl verify -CAfile ca.pem server.pem
2 To configure MongoDB to use certs on the Windows version (similar on other versions), edit the c:\data\mongod.cfg:
systemLog:
destination: file
path: c:\data\log\mongod.log
storage:
dbPath: c:\data\db
net:
port: 27017
bindIp: 127.0.0.1
ssl:
mode: requireSSL
PEMKeyFile: c:\data\server.pem
CAFile: c:\data\ca.pem
{allowConnectionsWithoutCertificates: true }
{allowInvalidHostnames: true }
You may need allowInvalidHostnames to True if you are using a self signed certificate.
3 To create a self-signed certificate for your MongoDB client (client1.pem):
openssl genrsa -out client1.key 2048
openssl req -key client1.key -new -out client1.req -subj "/C=US/ST=California/O=Company/CN=client1/emailAddress=user#domain.com"
openssl x509 -req -in client1.req -CA ca.pem -CAkey privkey.pem -CAserial ca.srl -out client1.crt -days 3650
type client1.key client1.crt > client1.pem
openssl verify -CAfile ca.pem client1.pem
Note: You will also need to use the client certificate in whatever tool you are using to admin the MongoDB server.
4 To enable SSL/TLS connections for MongoDB driver you may have to change the source files. Our unit Grijjy.Http shows how to enable the driver for ‘https’. Essentially you need to do 2 things to the Connection inside the Grijjy.MongoDB.Protocol unit probably within the method TgoMongoProtocol.Connect :
Set Connection.SSL := True;
Set the Connection.Certificate to the client1.pem you created.
You will have to do some testing, but I hope it points you in the correct direction to make it work. Would love your contribution to the open source project if you can.
As far as I can understand the sources, https://github.com/grijjy/DelphiMongoDB/ doesn't support authentication.
Also from the source, https://github.com/stijnsanders/TMongoWire doesn't either.
FireDAC Mongo uses the C Mongo client library, which supports authentication.
Our Open Source SynMongoDB.pas supports authentication, FPC and almost all Delphi versions (even pre-Unicode). Using variant late-binding to access the BSON/JSON content, it is pretty easy to work with it. Just check the corresponding documentation pages. You can write for instance:
var doc: variant;
...
doc := Coll.FindOne(5);
writeln('Name: ',doc.Name);
writeln('Number: ',doc.Number);
or
var docs: TVariantDynArray;
...
Coll.FindDocs(docs);
for i := 0 to high(docs) do
writeln('Name: ',docs[i].Name,' Number: ',docs[i].Number);
The TMongoClient.OpenAuth method supports both old/deprecated MONGODB-CR method, and the new SCRAM-SHA-1 method:
Client := TMongoClient.Create('localhost',27017);
try
DB := Client.OpenAuth('mydb','mongouser','mongopwd');
...
Note that even if it is part of the mORMot framework, this unit is stand-alone: you don't need to use the ORM, SOA, or MVC parts of the framework - even if it works very well with the ORM, and is able to convert SQL-like statements into MongoDB pipelines, which is a unique very powerful feature. Another unique feature is proper Decimal128 support.
Over a network, also ensure that you use a TLS connection to the server. SynMongoDB.pas can do that under Windows, with no external OpenSSL library needed (it uses the raw Windows SO API).
I'm trying to upload an SSL certificate for a custom domain in Bluemix, but I'm getting a generic error:
BXNUI2081E: An unknown error occurred when modifying certificates and keys: local:///deploySNIArtifacts/mbaasUtilities.xsl:793: Type of the left-hand side of / operator must be a nodeset..
I've followed the documentation, using openssl to generate a self-signed certificate, using the wildcard form of my domain. Any ideas on what I might have missed?
Here's a slightly redacted version of the output from the certificate:
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 17167458275182091963 (0xee3f10581c919ebb)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=Massachusetts, L=Littleton, O=IBM, OU=CLMServices, CN=*.clmsvcs.ibmcloud.com/emailAddress=<email removed>
Validity
Not Before: Apr 19 13:36:39 2016 GMT
Not After : May 19 13:36:39 2016 GMT
Subject: C=US, ST=Massachusetts, L=Littleton, O=IBM, OU=CLMServices, CN=*.clmsvcs.ibmcloud.com/emailAddress=<email removed>
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
<<data removed>>
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
<<data removed>>
The only case I've seen this error was when the private key you are using does not match the certificate.
You can run the following 2 commands to check if the private key and certificate you are trying to upload match:
openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in privateKey.key | openssl md5
Output from both commands needs to be the same.
This problem went away after a few days. I was able to upload the keys successfully.