I understand "certificate chain provided by the peer", if certificate provided by the peer is in the X509TrustManager, the certificate is trusted, so is it just need a checkTrusted instead of checkClientTrusted and checkServerTrusted, i don't understand what's the difference? Can anyone explains?
https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509TrustManager.html
void checkClientTrusted(X509Certificate[] chain, String authType):
Given the partial or complete certificate chain provided by the peer, build a certificate path to a trusted root and return if it can be validated and is trusted for client SSL authentication based on the authentication type.
void checkServerTrusted(X509Certificate[] chain, String authType):
Given the partial or complete certificate chain provided by the peer, build a certificate path to a trusted root and return if it can be validated and is trusted for server SSL authentication based on the authentication type.
In the early SSL/TLS protocols that existed when JSSE was designed, there was a significant difference between the constraints on and thus validation of server cert (linked to the key_exchange portion of the ciphersuite) versus client cert (mostly independent of key_exchange but controlled by CertReq); see rfc2246 7.4.2 and 7.4.4 (modified by rfc4492 2 and 3). Although authType is a String in both checkServer and checkClient, the values in it and the processing of them in the default TrustManager were significantly different.
TLS1.2, implemented (along with 1.1) by Java 7 and early 8, changed the cert constraints to also use a new signature_algorithms extension (from client) and field (from server) in combination with the prior fields. As a result in Java 7 up the interface you link is functionally replaced by a subtype class https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509ExtendedTrustManager.html which in addition to the new constraint checks also moves to the JSSE layer only in checkServer the hostname checking aka endpoint identification formerly done at a higher level like HttpsURLConnection (if at all). The extended class additionally takes an SSLSocket or SSLEngine argument (as applicable) which allows access to the additional information for sigalgs and hostname.
Finally TLS1.3, implemented in java 11 up and backported to 8u261 up, uses only extensions, now two of them, and not the ciphersuite at all, for cert selection and checking. In 1.3 the extended API is still called but the value in authType is meaningless and must not be used, and in at least some cases I have looked at is in fact empty, so the actual (rfc5280) validation is in fact the same for both directions. But as above checkServer does endpoint identification if applicable while checkClient does not.
See an actual difference in https://security.stackexchange.com/questions/158339/ssl-tls-certificate-chain-validation-result-in-invalid-authentication-type-d (note: 2017 was before TLS1.3 existed)
and compare javax.net.ssl.SSLContext to trust everything sslContext.init(keyManagerFactory.getKeyManagers(), ???, new SecureRandom()); .
Related
I am working on a web service project which requires that clients connecting to my service authenticate themselves via X.509 certificates as part of a Mutual Authentication TLS negotiation. In addition to linking the client certificate to a specific PKI trust chain, my requirements dictate that I must verify specific values within the certificate. Specifically, the subject DN must contain one OU with a predetermined value, and the certificate must contain one subjectAltName with a different predetermined value in URI format.
I am using Apache httpd 2.4.6 on a CentOS 7 system, and am able to satisfy most of these requirements fairly easily with standard Apache configuration directives leveraging common mod_ssl variables, with one notable exception: I cannot seem to find a variable that allows me to access a subjectAltName value in URI format. Looking at the mod_ssl documentation found here:
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html
I can see variables for the following subjectAltName formats:
SSL_CLIENT_SAN_Email_n - Client certificate's subjectAltName extension entries of type rfc822Name
SSL_CLIENT_SAN_DNS_n - Client certificate's subjectAltName extension entries of type dNSName
SSL_CLIENT_SAN_OTHER_msUPN_n - Client certificate's subjectAltName extension entries of type otherName, Microsoft User Principal Name form (OID 1.3.6.1.4.1.311.20.2.3)
Given that URI is a distinct and valid format for subjectAltName values as defined in RFC 5280 (X.509/PKI) section 4.2.1.6, I'm at a loss for why mod_ssl would not provide access to subjectAltNames in this format. Is there a variable that provides this functionality which I am simply not seeing in the documentation?
Further reviewing the mod_ssl source code, it is clear that extracting SAN values in URI format for use in variables is simply not currently supported, as noted by this comment:
/*
* Not implemented right now:
* GEN_X400 (x400Address)
* GEN_DIRNAME (directoryName)
* GEN_EDIPARTY (ediPartyName)
* GEN_URI (uniformResourceIdentifier)
* GEN_IPADD (iPAddress)
* GEN_RID (registeredID)
*/
in https://github.com/apache/httpd/blob/5f32ea94af5f1e7ea68d6fca58f0ac2478cc18c5/modules/ssl/ssl_util_ssl.c
As such, the answer to my question is apparently that there is not presently a variable I can use for this purpose, and fulfilling this requirement will necessitate a workaround (or an implementation of GEN_URI pushed to mod_ssl).
I have client server which uses opensl 1.0.2j, and using RSA:4096 key and certificate and want to force the server to use only the following ciphers.
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDH-RSA-AES128-GCM-SHA256
ECDH-RSA-AES128-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
My server side code will look like below.
method = SSLv23_server_method();
ctx = SSL_CTX_new(method);
SSL_CTX_set_cipher_list(ctx, "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256");
SSL_CTX_set_ecdh_auto(ctx, 1);
SSL_CTX_set_tmp_dh(ctx, dh);
SSL_CTX_set_tmp_ecdh(ctx, ecdh);
SSL_CTX_use_certificate_file(ctx, certFilePath, SSL_FILETYPE_PEM);
SSL_CTX_use_PrivateKey_file(ctx, privKeyPath, SSL_FILETYPE_PEM)
SSL_accept()
My client side code will look like as below
method = SSLv23_server_method();
ctx = SSL_CTX_new(method);
SSL_CTX_set_cipher_list(ctx, "ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-SHA256");
SSL_CTX_set_ecdh_auto(ctx, 1);
SSL_CTX_set_tmp_dh(ctx, dh);
SSL_CTX_set_tmp_ecdh(ctx, ecdh);
SSL_CTX_use_certificate_file(ctx, certFilePath, SSL_FILETYPE_PEM);
SSL_CTX_use_PrivateKey_file(ctx, privKeyPath, SSL_FILETYPE_PEM)
SSL_connect()
The last step ssl_accept() on the server fails with
err: 336027900 'error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol'
If i use ECDHE*RSA* or DHE*RSA* ciphers on the client side, it is working fine.
Could you please let me know what I am missing?
Edit: server's certificate(certFilePath) contains an RSA public key not the ECDH public key.
Meta: answer only up to TLS1.2; 1.3 no longer has keyexchange and authentication in ciphersuite.
First, it makes no sense to call both set_ecdh_auto and set_tmp_ecdh -- those are mutually exclusive. Also your server doesn't request client authentication, so configuring a self-cert&key on the client is useless. OTOH your server is using a selfsigned cert which probably isn't in the client's default truststore, so you may need to configure the client truststore (there are several approaches to doing that).
Second, 'static' ECDH ciphersuites are quite different from ECDHE suites, just as 'static' DH suites are different from DHE suites. Both static forms are not widely implemented and very little used because they generally offer no benefit; in particular OpenSSL 1.1.0 and up no longer implement them, so your code becomes obsolete in about a year if I remember the schedule correctly.
To be exact, DH-RSA suites require a cert containing a DH key (which permits keyAgreement), and for TLS<=1.1 the cert must be issued by a CA using an RSA key; for 1.2 this latter restriction is removed. No public CA will issue a cert for a DH key, and even doing it yourself isn't easy; see https://security.stackexchange.com/questions/44251/openssl-generate-different-type-of-self-signed-certificate and (my) https://crypto.stackexchange.com/questions/19452/static-dh-static-ecdh-certificate-using-openssl/ .
ECDH-RSA suites similarly require a cert containing an ECC key which permits keyAgreement, and issued by RSA if <=1.1; this is somewhat easier because the key (and CSR) for ECDH is the same as for ECDSA and only KeyUsage needs to differ. For your self-created and self-signed case, it's easy, just generate an ECC key and cert (automatically signed with ECDSA).
But last, this shouldn't cause 'unknown protocol'; it would cause 'no shared cipher' and handshake_failure. The code you've shown shouldn't cause 'unknown protocol', so you probably need to investigate and fix that first. You might try using commandline s_client instead especially with its -debug or -msg hooks, or -trace if you have compiled that in.
I am signing a PDF with Bouncy Castle and embedding an OCSP response in the PKCS7. I assemble the signed PDF with PDFBox, but I can't for the life of me get the resulting file to validate properly in Adobe Reader (the OCSP is not recognized). Since the OCSP responder requires signed requests, I have to embed the response in the file.
If someone would have any pointers at all, it would be much appreciated.
I presume it's easier to look at the actual signature/certs/OCSP than my code. The signed PDF is available here:
https://drive.google.com/open?id=0B_TaSaQW0YXteUgtbUlEa0NhcGc
And the Base64-encoded signature is here:
https://drive.google.com/open?id=0B_TaSaQW0YXtaEtPczRROTg4UDA
Edit:
When I look at the certificate in Adobe Reader, and check Revocation > Problems encountered, it says:
Certificate is not valid for the usage. Must sign the request.
The Revocation-section also says:
An attempt was made to determine whether the certificate is valid by doing
a revocation check using the Online Certificate Status Protocol (OCSP).
So it seems that the embedded OCSP is skipped altogether.
Edit 2:
As per mkl's suggestion I updated the nonce-extension, by changing the following line:
DEROctetString extValue = new DEROctetString(nonce);
To this:
DEROctetString extValue = new DEROctetString(new DEROctetString(nonce)));
Resulting in the following DER-structure:
[1] (1 elem)
SEQUENCE (1 elem)
SEQUENCE (2 elem)
OBJECT IDENTIFIER 1.3.6.1.5.5.7.48.1.2ocspNonce(OCSP)
OCTET STRING (1 elem)
OCTET STRING IKhVULz41m7JWTa4swZXJPBm6Zs=
But I still get the same error messages in Adobe Reader. I have attached the updated document and base64-encoded signature:
https://drive.google.com/open?id=0B_TaSaQW0YXtVjNqRWlxbXg4T0U
https://drive.google.com/open?id=0B_TaSaQW0YXtNC1CblZlUHV4dGs
Edit 3:
I compared the file to another version without the embedded OCSP response, and got this error in Prolems encountered in Adobe Reader:
Must sign the request.
Leading me to believe that the first part of the initial error was indeed from trying to validate the embedded OCSP-response:
Certificate is not valid for the usage.
I guess the certificate in question, would be the signing certificate of the OCSP-response. My own document is signed with the following certificate structure:
Root CA -> Bank (on EU Trust List) -> My Company
The OCSP is signed with the following structure:
Root CA -> External company (cert marked for OCSP signing)
Does the intermediary certificate in the document signing chain make the OCSP-signature invalid? Or can I somehow include missing pieces of the cert chain(s) to make it validate? Or is this perhaps not the problem?
OCSP Nonce encoding
The nonce extension in your OCSP response is encoded like this:
3405 45: [1] {
3407 43: SEQUENCE {
3409 41: SEQUENCE {
3411 9: OBJECT IDENTIFIER
: ocspNonce (1 3 6 1 5 5 7 48 1 2)
3422 28: OCTET STRING 'EZrf5DVM/y1QFGUfydwBSOsxZ6s='
: }
: }
: }
This most likely corresponds to the nonce extension as you sent it in your request.
Remember, though, that the value of an extension is wrapped in an OCTET STRING by definition. Thus, your actual nonce value is the sequence of bytes given by the ASCII values of the characters EZrf5DVM/y1QFGUfydwBSOsxZ6s=, i.e. something completely untyped as far as ASN.1 is concerned.
But RFC 6960 specifies, for the nonce extension, ASN.1 syntax that was missing in RFC 2560...
Nonce ::= OCTET STRING
(RFC 6960 sections 1 and 4.4.1)
So your nonce value has to be an OCTET STRING instead of untyped as far as ASN.1 is concerned.
Thus, please try and wrap the value you chose for your nonce in an OCTET STREAM (which then, according to the Extension definition, will be wrapped in yet another OCTET STREAM).
Revocation information for all certificates
To make verification succeed without additional revocation information requests, the signature must bring along revocation information for all certificates involved except the (trusted) root certificates and other certificates marked accordingly.
Thus, you do not only need revocation information for your signer certificate and the intermediary bank certificate but also for the OCSP certificates of your embedded OCSP responses (unless they have the id-pkix-ocsp-nocheck extension).
If I read the ASN.1 dumps correctly, the OCSP certificate in your case does not have that extension. Thus, Adobe Reader will try to receive revocation information for it online, and if that does not work, it won't use your embedded OCSP responses.
OCSP service TLS certificate
As your signature does not bring along all required revocation information. Adobe Reader tries to receive them online. While doing so, it runs into errors.
The detailed error information I get are
Certificate is not valid for the usage____________________________________________________________
Certificate is not valid for the usage____________________________________________________________
SSL certificate error.
And indeed, trying to access https://va1.bankid.no/ (the URL of the OCSP server) manually, I'm also been told about certificate issues.
You appear to get different errors. Did you install and trust some special certificates on your computer or in Adobe Reader?
We are using the self test suite provided by sonos (latest version from website) in order to test our service implementation. The test fails when checkiong if our server support SSL and TLS 1.0.
Failed ssl_validation test_support_tls_10 Instance Messages: Fail:
The partner must support at least one of the following cipher
suites:AES128, AES256, RC4-MD5 and RC4-SHA.The server does not support
TLS1.0 (expression is False)
Stopped ssl_validation test_support_secure_renegotiation Instance
Messages: Stop: One sessionRegegotiation element should be returned,
indicating that api.anghami.com supports secure session renegotiation
(expression is False)
Failed ssl_validation test_certificate_expiration Instance Messages:
Fail: A notBefore and notAfter element should be returned, indicating
that api.anghami.com has a date range for validity.
Stopped ssl_validation test_DNS_has_valid_x509_certificate Instance
Messages: Stop: A X.509_certificate element should be returned,
indicating that api.anghami.com has a valid X.509 certificate for the
DNS name (expression is False)
Please note that we have checked our server using:
the online certificate checking tool provided by Symantec and the results show that the certificate is valid and installed correctly and that our server clearly supports: TLS 1.2 | TLS 1.1 | TLS 1.0, along with 2 of the required ciphers (please check error message above).
In addition, test results with some screenshots and additional log files were posted on Basecamp.
Waiting for your feedback.
Regards
Based on the above your certificate is not set up for secure renegotiation and does not have a valid date range; these are both required in order for us to accept the certificate. We will follow up on basecamp.
From CherryPy 3.0 and onwards, one-way SSL can be turned on simply by pointing to the server certificate and private key, like this:
import cherrypy
class HelloWorld(object):
def index(self):
return "Hello SSL World!"
index.exposed = True
cherrypy.server.ssl_certificate = "keys/server.crt"
cherrypy.server.ssl_private_key = "keys/server.crtkey"
cherrypy.quickstart(HelloWorld())
This enables clients to validate the server's authenticity. Does anyone know whether CherryPy supports 2-way ssl, e.g. where the server can also check client authenticity by validating a client certificate?
If yes, could anyone give an example how is that done? Or post a reference to an example?
It doesn't out of the box. You'd have to patch the wsgiserver to provide that feature. There is a ticket (and patches) in progress at http://www.cherrypy.org/ticket/1001.
I have been looking for the same thing. I know there are some patches on the CherryPy site.
I also found the following at CherryPy SSL Client Authentication. I haven't compared this vs the CherryPy patches but maybe the info will be helpful.
We recently needed to develop a quick
but resilient REST application and
found that CherryPy suited our needs
better than other Python networking
frameworks, like Twisted.
Unfortunately, its simplicity lacked a
key feature we needed, Server/Client
SSL certificate validation. Therefore
we spent a few hours writing a few
quick modifications to the current
release, 3.1.2. The following code
snippets are the modifications we
made:
cherrypy/_cpserver.py
## -55,7 +55,6 ## instance = None ssl_certificate = None ssl_private_key
= None
+ ssl_ca_certificate = None nodelay = True
def __init__(self):
cherrypy/wsgiserver/__init__.py
## -1480,6 +1480,7 ##
# Paths to certificate and private key files ssl_certificate = None ssl_private_key = None
+ ssl_ca_certificate = None
def __init__(self, bind_addr, wsgi_app, numthreads=10, server_name=None, max=-1, request_queue_size=5, timeout=10, shutdown_timeout=5):
## -1619,7 +1620,9 ##
self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) if self.nodelay: self.socket.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
- if self.ssl_certificate and self.ssl_private_key:
+ if self.ssl_certificate and self.ssl_private_key and \
+ self.ssl_ca_certificate:
+ if SSL is None: raise ImportError("You must install pyOpenSSL to use HTTPS.")
## -1627,6 +1630,11 ## ctx = SSL.Context(SSL.SSLv23_METHOD) ctx.use_privatekey_file(self.ssl_private_key) ctx.use_certificate_file(self.ssl_certificate)
+ x509 = crypto.load_certificate(crypto.FILETYPE_PEM,
+ open(self.ssl_ca_certificate).read())
+ store = ctx.get_cert_store()
+ store.add_cert(x509)
+ ctx.set_verify(SSL.VERIFY_PEER | SSL.VERIFY_FAIL_IF_NO_PEER_CERT, lambda *x:True) self.socket = SSLConnection(ctx, self.socket) self.populate_ssl_environ()
The above patches require the
inclusion of a new configuration
option inside of the CherryPy server
configuration,
server.ssl_ca_certificate. This
option identifies the certificate
authority file that connecting clients
will be validated against, if the
client does not present a valid client
certificate it will close the
connection immediately.
Our solution has advantages and
disadvantages, the primary advantage
being if the connecting client doesn’t
present a valid certificate it’s
connection is immediately closed.
This is good for security concerns as
it does not permit the client any
access into the CherryPy application
stack. However, since the restriction
is done at the socket level the
CherryPy application can never see the
client connecting and hence the
solution is somewhat inflexible.
An optimal solution would allow the
client to connect to the CherryPy
socket and send the client certificate
up into the application stack. Then a
custom CherryPy Tool would validate
the certificate inside of the
application stack and close the
connection if necessary; unfortunately
because of the structure of CherryPy’s
pyOpenSSL implementation it is
difficult to retrieve the client
certificate inside of the application
stack.
Of course the patches above should
only be used at your own risk. If you
come up with a better solution please
let us know.
If the current version of CherryPy does not support client certificate verification, it is possible to configure CherryPy to listen to 127.0.0.1:80, install HAProxy to listen to 443 and verify client side certificates and to forward traffic to 127.0.0.1:80
HAProxy is simple, light, fast and reliable.
An example of HAProxy configuration