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.
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 purchased my SSL certificate from GoDaddy.
I made the common name www.mywebsite.com.
In my DNS settings I have the website forwarding from the naked domain to the www.mywebsite.com.
I removed any settings inside Heroku regarding the SSL certificate from the GUI.
Then I went through the instructions here.
To recap, I generated my server.key by first creating the crs files and sending those to GoDaddy.
I purchased the $20/mo endpoint.
GoDaddy gives me a downloadable ZIP for my certificates, one with one certificate, and one with 3 certificates inside of it.
I run the following command to install the bundled version first with the following failing message that follows:
heroku certs:add server.crt server.key --type endpoint
No certificate given is a domain name certificate.
The reason I even tried to use the bundle is that my SSL doesn't work in firefox, and intermediary cert is not being included. After looking around for an answer on this, I couldn't find one.
So to get my website back up and running in the short term, I decided to just do what I did before, and upload the single cert. That works, but not really.
Now I get this message when I run the cUrl test:
* error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
Also, my website is down. :(
How do I fix this?
The answer in my case seems to be that purchasing an SSL cert is not necessary on Heroku. When you purchase a paid hosting package they provide SSL certificates by default without having to buy their SSL add-on endpoint.
There are likely other use-cases for using a paid SSL cert, but in my case I didn't have to do that.
If this answer helped you please upvote this question as some people seem to think it's a question worth down voting.
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I'm trying to force Apache to authenticate users by their personal certificates before letting them access site's content, on my company's LAN website.
I've tried so far having configured the httpd-ssl.conf like this :
SSLVerifyDepth 0
SSLVerifyClient require
SSLProxyEngine off
When I go to https://localhost via firefox, it would show me a dialog with the list of my imported certificates to choose one.
That's OK exactly what I expected. But then I wonder "So, how can I give a test/verification against my client's certificate ?". At this point all the certificates that I've tried from the cert-dialog (all self-signed certs that I've created my own) were rejected by server.
Some googling led me to the a directive named "SSLCACertificateFile". That's the path to a certificate file that should be the root CA of all client's certificates. In other words, any certificates from client that was issued by this CA would be accepted as valid. (more about it could be found here)
But, the problem is, when I specify a concrete CA certificate file that way, Firefox stop showing me the certificate-dialog-box. The file "httpd-ssl.conf" like this :
SSLCACertificateFile C:/(...)/apache2/server_certs/ca.pem
SSLVerifyDepth 0
SSLVerifyClient require
SSLProxyEngine off
Instead, Firefox showed me an error notification with error code : "ssl_error_handshake_failure_alert"
I'm sure the CA certificate file "ca.pen" was in correct format cause it's the original one in installation pakage that I've downloaded. (Actually, it's in a free product named uniServer)
I've tested this against IE, Chrome, which results are all the same. I've tried testing some other "ca.pem" files (all self-signed), and the result refused to change.
So, my question is quite simple : what's wrong with specifying a concrete CA file for apache directive "SSLCACertificateFile" ?
If you can tell me answer for that, then would you mind telling me some more way to verify the cleint-certs, such as CN, issued-date, validate-to, ... etc
Thanks & highly appreciate any suggestion
SSLVerifyDepth 0 "means that self-signed client certificates are accepted only", which doesn't seem to be what you're trying to do (since you've set up a CA).
You'd certainly want to increase this to at least 1 (or more if the client may present a certificate chain).
openssl s_client -connect your.server.name:443 should give you a list of the CA names advertised by the server. Firefox will only offer you a choice of certificates that can be chained to these issuers.
For authorisation conditions, you might be interested in SSLRequire (or its successor, depending on the version of Apache Httpd you're using).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
After installing a new SSL certificate under Apache, I used the
RapidSSL Certificate Installation Checker to validate my secured domain. After typing in my domain, I received a warning and this message:
Two certificates were found with the same common name. The certificate installation checker cannot
determine which is the correct certificate for the Web server. Remove the incorrect certificate
and then test again.
My Apache / SSL configuration is such that I list my new SSL certificate in the same file along with the relevant certifying authorities. In the SSL configuration, I specify these options:
SSLCertificateFile /path/to/cert-with-ca-chain.txt
SSLCertificateChainFile /path/to/cert-with-ca-chain.txt
Based on comments in the Apache SSL module, such a configuration should be possible:
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
I looked online for a resolution to this issue, but could find none.
After a while, I did resolve the issue myself. I want to see what
other people have to say, and then will post my solution so people
doing Apache / SSL setups in the future will have this resource at
their disposal.
Well the solution is obviously not to use that configuration but to use a file with a single certificate for the SSLCertificateFile and the CA's own bundle file for the SSLCertificateChainFile. Exactly how the CA gave it to you in fact. There's no advantage in doing the extra processing, especially when it comes time to renew and you can't remember what you did.