I am trying to obtain the CRL from an OpenXPKI server (the default configuration is used). Requesting and polling of a certificate is possible.
On the OpenXPKI server, I revoked some certificate, created the CRL and published the list. To obtain the CRL I tried different approaches.
First approach:
X509CRL crl = client.getRevocationList(jscepCertificate, jscepKeyPair.getPrivate(),
certificate.getIssuerX500Principal(), certificate.getSerialNumber());
Second approach:
X509CRL crl = client.getRevocationList(jscepCertificate, jscepKeyPair.getPrivate(),
crlIssuer, crlSerialNumber);
On the server my CRL has the following information:
CRL Serial: 511
CRL Issuer: CN=CA ONE,OU=Test CA,DC=OpenXPKI,DC=ORG
Items: 25
When I try the above code examples (and also some other) I get following error on the CRL requester:
org.jscep.transaction.OperationFailureException: Operation failed due
to badCertId
And on the OpenXPKI server I get the following error:
openxpki.application.ERROR:12156 [OpenXPKI::Service::SCEP::Command::PKIOperation
(/usr/lib/x86_64-linux-gnu/perl5/5.20/OpenXPKI/Service/SCEP/Command/PKIOperation.pm:255);
scep-server-1()#f68c] SCEP getcrl - no issuer found for serial 511 and
issuer DC=ORG,DC=OpenXPKI,OU=Test CA,CN=CA ONE
Always no issuer found for serial XXX and issuer YYY (XXX and YYY depend on the send information of the CRL request).
Please, could anyone help me or give me some advice? - Thanks in advance!
I solved the problem with the help of the JSCEP and OpenXPKI communities. The problem is that the DN of the issuer is reversed, this means e.g. CN=CA,OU=Test CA,DC=OpenXPKI,DC=ORG is changed to DC=ORG,DC=OpenXPKI,OU=Test CA,CN=CA ONE and the getCRL from the OpenXPKI has no entry for the reversed issuer.
An easy fix is to reverse the issuer for the getCRL request (check OpenXPKI fix) by changing the code from the get_getcrl_issuer_serial.pm file. Add the following code in line 107:
$issuer = join ",", reverse split (/,/, $issuer);
A solution for the future would be to make the getCRL logic requester independent and to order the issuer on the request.
Related
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.
Recently I set up a mail server (mailcow) with help of the following tutorial. I tried to login with Outlook, but Outlook says that the certificate can not be verified. Why is the value of the issued to field mail.example.org and not to xxx.xxx.xx?
mailcow.conf:
MAILCOW_HOSTNAME=xxx.xxx.xx
HTTP_PORT=8080
HTTP_BIND=0.0.0.0
HTTPS_PORT=8443
HTTPS_BIND=0.0.0.0
SMTP_PORT=25
SMTPS_PORT=465
SUBMISSION_PORT=587
IMAP_PORT=143
IMAPS_PORT=993
POP_PORT=110
POPS_PORT=995
SIEVE_PORT=4190
DOVEADM_PORT=127.0.0.1:19991
SQL_PORT=127.0.0.1:13306
ADDITIONAL_SAN=
# Skip running ACME (acme-mailcow, Let's Encrypt certs) - y/n
SKIP_LETS_ENCRYPT=n
# Skip IPv4 check in ACME container - y/n
SKIP_IP_CHECK=n
# Skip HTTP verification in ACME container - y/n
SKIP_HTTP_VERIFICATION=n
In the configuration file I set SKIP_LETS_ENCRYPT = y and generated the ssl certificate with letsencrypt myself. Look here.
why PDF Reader doesn’t show the embedded OCSP Response?
I haven't even used crlClient:
MakeSignature.signDetached(sap, new BouncyCastleDigest(), es, chain, null, ocspClient, tsClient, 0, MakeSignature.CryptoStandard.CMS);
// chain[0] - signer certificate
// chain[1] - OperCA certificate (signer's issuer)
// chain[2] - RootCA (OperCA's issuer)
PDF revocation tab details shows:
The selected certificate is considered valid because it does not
appear in the Certificate Revocation List (CRL) that is contained in
the local cache.
The CRL was signed by "B-Trust Operational CA QES <[hidden email]>" on 2014/02/19 07:53:35 +02'00' and is valid until 2014/03/21 07:53:35 +02'00'.
I want to achieve the Figure 3.8 A digital signature with an embedded OCSP response, from Bruno Lowagie's free White Paper document.
What do I do wrong or miss?
Here is the Certification path and sample pdf.
Best Regards, Valentino
The actual issue is that even when PDF has embedded only OCSP response,
Acrobat Reader doesn't show it, but shows local CRL instead.
This is caused of non-conforming, to RFC6960 or RFC2560, OCSP certificate.
Wrong OCSP certificate path:
Root CA -> Operational CA -> Client certificates (certificates checked with OCSP)
Root CA -> OCSP
Right OCSP certification path:
Root CA -> Operational CA -> Client certificates (certificates checked with OCSP)
Operational CA -> OCSP
Have called many restful services from asp before - but this one has me stumped.
First my func looks like
Set objHTTP = Server.CreateObject("MSXML2.ServerXMLHTTP")
with objHTTP
.open "post", x_posturl, False
.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
.send x_xmlstr
end with
and the error returned is
msxml3.dll error '80072f0d' The certificate authority is invalid or
incorrect
so, googled a bit and suggestion was to add line
.setOption 2, 13056
this gives error
msxml3.dll error '80072f0c' A certificate is required to complete
client authentication
I then contacted service supplier and they suggested
Click on the certificate error next to the address bar, view the
certificate, select Details, select Copy to File, and download it to a
file. Install that into your trusted certificates on your server to
stop the error appearing when trying to submit data.
So, tried that using instructions here - but still no joy, any help appreciated
It seems like the server located at x_posturl has a certificate that is misconfigured, or that your client computer doesn't contain/recognize the certificate's root authority (most likely). There are a few options to fix:
Have them fix their certificate if it's misconfigured.
If their certificate is valid, but with a root authority your machine doesn't recognize, then you need to install the root authority certificate locally.
Instruct MSXML2.ServerXMLHTTP to ignore certificate errors, which appears to be answered here: VBA ServerXMLHTTP https request with self signed certificate
Change x_posturl to start with http:// instead of https://— if it's supported by the provider. Would not recommend this in a production scenario though.
Can you share specifically what x_posturl is? We should be able to debug by looking at the SSL handshake.
I was able to find the solution by passing in a param.
objHTTP.SetOption 2, objHTTP.GetOption(2)
Dim objHTTP
Set objHTTP = Server.CreateObject("MSXML2.ServerXMLHTTP")
objHTTP.SetOption 2, objHTTP.GetOption(2)
objHTTP.Open "post", x_posturl, False
objHTTP.SetRequestHeader "Content-Type", "application/x-www-form-urlencoded"
objHTTP.Send x_xmlstr