I am trying to use AIA fetching to reconstruct a certificate chain, but only leaf certificates have a valid URIs. All intermediate nodes that I tested on either the CA Issuer is missing(facebook) or the URI returned 404.
At the time of this article AIA fetching was valid.
My questions are: Is AIA fetching still working? If not, is there any chance that I can reconstruct the whole certificate chain if I only have the leaf certificate?
I just realized there was a bug in my code and I was introducing a '\n' at the end of the URI. Don't be me, guys.
Related
This is a bit of a super duper specific question, but who knows there's someone out there that can help me.
I happen to have Philips Hue Bridge and I would love to know what personal information it is sharing with the outside world. Using tcpdump on my router I figured the Hue Bridge has a rather talkative personality. But because it talks over SSL tunnels, I have no idea what it says. So what I did is I setup a SonicWall with SSL-DPI with a CA, got root access to the Hue Bridge and found the application that does the talking to wws://ws.meethue.com (its called websocketcd). I then replaced the root certificate on the Hue Bridge, adjusted the cipher to match the Sonicwall and now I am stuck due to boost.asio trowing an validation error of my certificate:
error:14090086:lib(20):func(144):reason(134)
For those not too familiar with the error codes, this is what they mean:
lib(20) is ERR_LIB_SSL
func(144) is SSL_F_SSL3_GET_SERVER_CERTIFICATE
reason(134) is SSL_R_CERTIFICATE_VERIFY_FAILED
To verify it's not my SonicWall or certificate that is causing the problem, I executed openssl s_client -connect ws.meethue.com:443 -CAfile ca.pem from the Hue Bridge and that validates the chain perfectly fine, the same way as the original certificate. I also verified that the application is loading my root certificate and cipher correctly (because if change the cipher, I get a cipher error error). Also in my browser, I can visit https://ws.meethue.com without certificate errors. Here's my self made certificate chain, in case someone wants to check it: https://gofile.io/d/5msjoJ (password for download/key 1020304050, it's a temporary key that only exists in my local test env. so it's safe to share ;-)
If websocketcd wasn't a binary file, the problem was super easy to solve using set_verify_mode, but unfortunately it is a binary and that makes life significantly more complicated.
Is there anyone who can give me advice how to make this blob called websocketcd with boost.asio in it accept my root certificate? What I tried too: letting it communicate without ssl and with ssl without encryption (eNULL:aNULL ciphers). I am a bit hesitant to share the blob but for those who have a Hue Bridge too, it's located at /usr/bin/websocketcd.
Perhaps you can use strace (or maybe even ltrace) to spot which certificate paths it is using for root authorities.
If it uses a single file, you might be abel to hack it by replacing it with a CA that verifies your MITM certificate.
Sometimes the file can contain multiple certificates, so worth appending/prepending yours.
If you're in luck, there will be a readdir on a directory containing certificates. If so, you should be able to add your root certificate (in PEM form) there and **remember to run c_rehash on that directory.
For those interested: after some 20hrs, I figured that websocketcd requires a certificate revocation list for each CA in the chain (which do not have to have any revoked serials). These CLRs need to be included in the root CA file that is loaded using the ca-filename argument. I was not aware that Boost Asio could demand that a CLR is present for each CA, but apparently, they (Signify) managed to do so.
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.
All the informations I found show only how to activate SSL key + SSL cert, like this one.
#ssl_keyfile = /var/lib/opscenter/ssl/opscenter.key
#ssl_certfile = /var/lib/opscenter/ssl/opscenter.pem
#ssl_port = 8443
But not how has the SSL intermediate to be integrated?
There seems no ssl_intermediate file option.
Appending intermediate cert to the certfile is not recognized by opscenter
webserver.
OpsCenter developer here. This post is pretty old but it recently came across my radar, answering for posterity...
The PEM format allows multiple certificates to be concatenated together. For certs with a trust chain, add the whole chain into a single PEM file and point ssl_certfile at it. Digitcert has a nice simple document detailing certificate concatenation in PEM files: https://www.digicert.com/ssl-support/pem-ssl-creation.htm
Edit: Just saw that you mentioned that appending didn't work, hard to say what's going on but if you append the full trust chain (not just the nearest intermediate) appending should work as expected.
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So according to:
http://support.godaddy.com/help/article/5238/installing-an-ssl-certificate-in-apache
There is the following line to edit in ssl.cof for Apache 2.x:
SSLCertificateChainFile /path/to/intermediate/bundle/file
Well, I received gd_bundle.crt and my domain's certificate in a zip file. But hey, which one is the intermediate/bundle/file - could it possibly be gd_bundle.crt or is it anyone from their repository:
https://certs.godaddy.com/anonymous/repository.seam
Because I've already filled one line with gd_bundle.crt so my guess it is another file, but which one out of that repository link?
Thank you.
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
SSLCACertificateFile /etc/httpd/conf/gd_bundle.crt
This are the four lines to be configured out of which two for sure are ok but the other two I do not know, specially where does gd_bundle.crt go and which certificate is it that I'm missing that didn't come in the zip file and took me all the road up to the repository link in which I don't know on which file to decide to download an apply.
SSLCertificateFile /etc/httpd/conf/subgram.com.crt
SSLCertificateKeyFile /etc/httpd/conf/server.key
SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt
SSLCACertificateFile /etc/httpd/conf/gd_bundle.crt
I will answer your question, but I'd like to kindly point you in the direction that will help you get better assistance in the future before I do.
First, there is a reason your question hasn't got much attention. It is asked in a way which is not going to get answers from the gate. 1) This is more of a question for serverfault, since it has to do more with web server administration than programming. 2) you didn't mention apache in the title. 3) You mention a specific company, Godaddy, something like "Installing an SSL certificate in Apache 2.x" would probably be better, and then mention the specifics about how your CA issues a certificate. This is a really common question, and there are probably existing threads which it is clear you didn't read before asking a question. This goes beyond your single problem, but will help you better answer every single question you have in the future a bit better. See http://www.catb.org/esr/faqs/smart-questions.html
This is probably an excellent opportunity to read up on some documentation about how SSL certificates work, and how they are configured in Apache as well.
Because I've already filled one line with gd_bundle.crt so my guess it
is another file, but which one out of that repository link?
None of them, that link only contains the Certificate Chain and Root Certificates.
Rather than try to describe what a Certificate Chain file is, IBM has done a much better job than I. This is step #1 in understanding how to solve your problem:
How certificate chains work
When you receive the certificate for another entity, you might need to
use a certificate chain to obtain the root CA certificate. The
certificate chain, also known as the certification path, is a list of
certificates used to authenticate an entity. The chain, or path,
begins with the certificate of that entity, and each certificate in
the chain is signed by the entity identified by the next certificate
in the chain. The chain terminates with a root CA certificate. The
root CA certificate is always signed by the CA itself. The signatures
of all certificates in the chain must be verified until the root CA
certificate is reached.
This means basically, that the Certificate Chain file is what you will need in order for your certificate to be properly verified. A .crt file indicates it contains public, private, and root certificate files in one file, or some combination thereof.
Step #2
A .pem file usually means just one public certificate, this is the file you will use for SSLCertificateFile. Naming this file with .crt is only canonically correct if theres more than one cert in there, which most likely there is not if you are getting a cert from your CA. You mentioned you received some files from Godaddy, one of them is going to be this file.
Step #3
SSLCertificateKeyFile will be a private key file that was provided at some point after / during your certificate was issued. I can't say exactly what Godaddy's process, I can only describe the fundamentals of the process, and each CA is different in how they issue certificates. Don't forget to set the proper permissions on this certificate (in fact I think Apache will fail to start if this file is not set to 600 permissions).
This should give you enough information to go on to get up and running. Anything else that involves navigating Godaddy's SSL issuance process is a question more for Godaddy support than StackOverflow / ServerFault.
Good luck.