Wanted to know about the pros and cons of using either "memcmp" or "strcmp" for validating the certificates exchanged during SSL Handshake.
My code converts the X509 certificates into PEM format and then do the string comparison to validate the certificates.
Are there any issues which are associated with using strcmp OVER memcmp for validating the certificate received during handshake against a verified certificate already placed on the server?
From your description it is hard to know what you do with memcmp or strcmp, but I assume, that you want to check the common name or subject alternative names against the hostname. There were others which used strcmp instead of memcmp for this which resulted in lots of security reports in 2009, see CVE-2009-2408 (firefox), CVE-2009-2702 (KDE), CVE-2009-3767 (OpenLDAP) and some more.
Related
My client send me three files from Go-Daddy (86f8ac00fcd77994.crt, 86f8ac00fcd77994.pem and gd_bundle-g2-g1.crt). I need create a jks keystore from this files. Is it possible? Thanks!
PD: Sorry for my english!
Yes but you don't want to.
Java uses keystore files like JKS, and KeyStore objects in memory, to store two (or three) different kinds of information but many people imprecisely call both of them certificates and don't understand the huge and critical difference. Specifically (and changing the order from the javadoc):
a TrustedCertificate entry contains "[one] certificate ... belonging to another party. .... This type of entry can be used to authenticate other parties."
a PrivateKey entry contains a privatekey PLUS a certificate CHAIN "used by a given entity for self-authentication".
for completeness, some keystores can contain a SecretKey entry, but JKS cannot, and even with those that can this capability is rarely used.
The files you have are all certificates (one in the hex-named files, several in the bundle file), not privatekeys. You can import each of them into a TrustedCert entry, but TrustedCert entries are only used to validate the other end of a communication -- i.e. when you connect to a server, the TrustedCert entries are used to validate that server's cert, and if you accept connection from a client and request client auth (which is not the default and is rare), the TrustedCert entries are used to validate that client's cert. But since this cert was issued by GoDaddy, if it is used correctly (with its chain) by a server or client you communicate with, you don't need any TrustedCert entries because it validates against a root already in Java's default truststore.
If you wanted to use this cert to authenticate 'yourself' (that is, your system) -- for example if you wanted to run a TLS server (possibly but not necessarily an HTTPS web server) identified by this cert -- you would need a PrivateKey entry, not any TrustedCert entries, and you can't create a PrivateKey entry because you don't have the privatekey. The person who obtained this certificate from GoDaddy does have the privatekey, because the certificate request process requires it, so they could e.g. run a server, but they didn't give it to you so you can't.
Thus the answer to the question you asked -- can you put these certs in a JKS -- is yes, you can. But it's a complete waste of time, because the resulting JKS cannot be used for anything and is worthless.
I have written a TLS code which is doing mutual authentication at Java, so client is sending its certificate after server sends its certificate. I would like to validate all the certificates in certificate chain by OCSP which is coming from client side to server side.
I have written my loop logic as assuming that last certificate is root(CA) certificate in the chain and not to send any OCSP query for it;
int certificateChainSize= x509Certificates.length;
// Verifies certificate chain respectively (issuer certificate required).
CertificateResult response = null;
try {
for (int i = 0; i < certificateChainSize-1 ; i++) {
response = client.verify(x509Certificates[i], x509Certificates[i+1]);
}
} catch (OcspException e) {
e.printStackTrace();
}
When I test TLS and get Wireshark capture, I realized that Google Chrome as client has been sending certificate chain without root. As a result; intermediate certificate is not queried because of loop logic, because my code assumed the intermedite certificate is root.
How can I force client to send all nodes of the certificate chain?
Thanks
I realized that Google Chrome as client has been sending certificate chain without root.
That is perfectly normal and the only correct behavior.
The root certificate is the trust anchor which has to be local to the party validating the certificate. Even if it is send it should be ignored when validating the certificate, i.e. only a local trust anchor should be used - otherwise a man in the middle could just provide his own certificate chain including his own root certificte. This means that in this case the server must have the root certificate already locally and thus there is no need for the client to send it.
In other words: don't try to change how Chrome behaves but instead adjust your expectations (and your code) on what the correct behavior is.
I agree with Steffen but to give some more facts, here is what TLS 1.3 explicitly says:
certificate_list: A sequence (chain) of CertificateEntry structures,
each containing a single certificate and set of extensions.
and
The sender's certificate MUST come in the first
CertificateEntry in the list. Each following certificate SHOULD
directly certify the one immediately preceding it. Because
certificate validation requires that trust anchors be distributed
independently, a certificate that specifies a trust anchor MAY be
omitted from the chain, provided that supported peers are known to
possess any omitted certificates.
and finally about ordering:
Note: Prior to TLS 1.3, "certificate_list" ordering required each
certificate to certify the one immediately preceding it; however,
some implementations allowed some flexibility. Servers sometimes
send both a current and deprecated intermediate for transitional
purposes, and others are simply configured incorrectly, but these
cases can nonetheless be validated properly. For maximum
compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which
MUST be first.
So Chrome is correctly applying this specification. You need to change your end to cope with it.
I know basic steps of a TLS Handshake but I don't have knowledge about detailed verification steps of certificates during TLS. My question is at below;
Let us assume that our system supports OCSP/CRLs verification. In this case, is the first step to verify incoming certificate using CRLs or OCSP Responder? Or look for the incoming certificate is in TrustStore or not, at first?
Thanks four your help
You will probably not find a definitive document on that, in part because people have shifted away from these 2 methods of revocation check (they are disabled by default in some browsers or when enabled do not produce very useful UI)
Nowadays people prefer OCSP Stapling (see https://casecurity.org/2013/02/14/certificate-revocation-and-ocsp-stapling/ for some reasons) over CRLs or OCSP.
But to go back precisely to your question, since both CRLs and OCSP typically mean going to fetch something remotely, this needs network access and can create delays. So if you have a local TrustStore with all the certificates you should first check that, before having to do a remote call.
Also the CABForum Baseline Requirements (at https://cabforum.org/baseline-requirements-certificate-contents/) specify that CRLs endpoints MAY be present in a certificate but OCSP endpoint MUST be present, except if you are doing OCSP Stapling instead.
On top of that EV certificates mandate OCSP.
So, in short it may make sense to do things in this order:
Check in local TrustStore
Do an OCSP query
Download a CRL
Note that nowadays you have also other options:
DANE, hence checking DNS TLSA records
Certificate Transparency Logs
oneCRL / CRLset
Today someone asked me if it was possible to hide the "Acceptable client certificate" list in the SSL connection information. Spontaneously, my answer was no, but according to the RFC it seems to possible.
openssl s_client -connect www.test170.com:443 -state
[...]
Acceptable client certificate CA names
/C=FR/ST=DPT/L=CITY/O=COMPANY/CN=CA_own
[...]
The idea is to hide this informations and let client send the good certificats.
((...These distinguished names may specify a desired distinguished name
If the certificate_authorities list is empty, then the client MAY
send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary.))
Someone know how I can hide these informations?
The servers are running with apache2.2 and 2.4.
I try to play with SSLCADNRequestPath path_empty_file but for now it doesn't work.
I have written small Java 7 Client and Server application. I have keystore with 3 Self-signed X.509 RSA Certificates. When client connects through SSL, server sends SSL Certificate message with only one certificate. I am bit new to SSL/TLS. I also looked at JSSE code sun.security.ssl.X509KeyManagerImpl, and found below comments:
/*
* Return the best alias that fits the given parameters.
* The algorithm we use is:
* . scan through all the aliases in all builders in order
* . as soon as we find a perfect match, return
* (i.e. a match with a cert that has appropriate key usage
* and is not expired).
* . if we do not find a perfect match, keep looping and remember
* the imperfect matches
* . at the end, sort the imperfect matches. we prefer expired certs
* with appropriate key usage to certs with the wrong key usage.
* return the first one of them.
*/
private String More ...chooseAlias(List<KeyType> keyTypeList,
Principal[] issuers, CheckType checkType)
Comment is pretty clear that server will send single best matching certificate but I don't seem to understand the reason. Like in my case, I want server to send all 3 certificates, so client can pick one and validate the chain. And also, if my client doesn't have the certificate that server sends, the connection is dropped with SSLHandshakeException 'No trusted certificate found'. So my question is that why can't server send all 3 certificates if the client requested information (from ClientHello) matches with all 3 certificates ? Is it something to do with TLS 1.0 vs TLS 1.2 ?
The TLS handshake protocol only provides for the transmission of one client end-entity certificate (this is also the case for server certificates). Intermediate certificates can be transmitted, but what you seem to want - transmission of multiple end-entity certificates - is not possible.
The structure of the TLS Server / Client Certificate message is defined in RFC 5246 (TLS 1.2) section 7.4.2:
Structure of this message:
opaque ASN.1Cert<1..2^24-1>;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
In regards to which certificate the client selects to present, if you configure your server to advertise its trusted CAs for client certificate validation (the certificate_authorities field of the CertificateRequest message; see below), then the client-side code that selects the certificate to present ought to select a certificate that is certified by one of the advertised CAs.
7.4.4. Certificate Request
...
Structure of this message:
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20), (255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
...
certificate_authorities
A list of the distinguished names [X501] of acceptable
certificate_authorities, represented in DER-encoded format. These
distinguished names may specify a desired distinguished name for a
root CA or for a subordinate CA; thus, this message can be used to
describe known roots as well as a desired authorization space. If
the certificate_authorities list is empty, then the client MAY
send any certificate of the appropriate ClientCertificateType,
unless there is some external arrangement to the contrary.
And, from section 7.4.6:
If the certificate_authorities list in the certificate request
message was non-empty, one of the certificates in the certificate
chain SHOULD be issued by one of the listed CAs.
Bad luck, you can only send one. See RFC 2616 &ff.