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.
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.
From SSL2BUY I have the text for a certificate starting with "-----BEGIN CERTIFICATE-----" down to "-----END CERTIFICATE-----". There is no download option just an email option (but that person isn't available) how do I convert the encrypted text between the 'begin' and 'end' statements to an actual certificate?
There are also 4 sections within this page; Servers, PKCS7, Root and Intermediate. How do these all interact?
SSL has been a bane of my life for a long time and I need to conquer this once and for all -_-.
Any assistance will be much appreciated.
I would like to inform you that Servers Certificate and PKCS7 Certificate are different formats of certificate.
PKCS7 format certificate is used in java based server like Tomcat and if you are not using Tomcat you can disregard it.
If you are using a server like IIS, cPanel, Apache etc then you will need to install "Server Certificate". You need to paste the certificate in notepad and save it with .cer extension.
If you are using a windows based server(IIS) then you will need only 1 file to install there which is "server certificate". On Windows based servers, root & intermediate certificates came preinstalled so you can skip that, they are not needed to install again.
If you are servers like Apache, cPanel, Nginx, Plesk, etc then you need to install the main domain certificate and CABundle(combination of the Root and Intermediate certificate).
Please Note:
For all leading CA's (Comodo, Digicert and GlobalSign) all the Root and Intermediate certificates are different. Please suggest your product name so I am able to assist in that particular product which Root and Intermediate certificate has to be used.
Please let me know the server type you are using such as Apache, IIS, cPanel, etc.
I am trying to upload the SSL certificates for my OpenShift gear's alias. I used the instructions here: http://cloudhostingsource.com/setup-ssl-certificate-openshift/
I am stuck however at the uploading part - I have already genereated the CSR, activated the certificate. Every time I try to upload the files it takes me back to the same page without so much as a notification.
Comodo SSL sent me 4 files:
AddTrustExternalCARoot.crt
COMODORSAAddTrustCA.crt
COMODORSADomainValidationSecureServerCA.crt
myApp.crt
How do I upload these? There are three fields to upload for Openshift... Which do I load into SSL Certificate? Certificate chain? I have my private key and I know the keypass.
Thanks
Just wanted to post an update for this for users who run into this issue in the future... I'm not sure if it was because I had added a public SSH key via the RHC setup but nothing I did (no permutations of copy paste chaining, switching files around) would work via the file uploader.
In the end, before deciding to call Red Hat and QQ, I used the command line console to add the SSL files...
Here is the command I used:
rhc alias update-cert php www.myapp.com --certificate myApp.crt --private-key myApp.key --passphrase mypass
This link includes more info: https://access.redhat.com/documentation/en-US/OpenShift_Online/2.0/html/User_Guide/Using_Custom_SSL_Certificates1.html
TLDR: You don't need to combine any of the Comodo files, just use your file #4, your privatekey, and your passphrase (if you have one)
Thats right!
First combine public with bundle:
cat dom_com.crt dom_com.ca-bundle >> dom_com.ALL.bundle
and upload both:
rhc alias update-cert app dom_com \
--certificate dom_com.ALL.bundle \
--private-key dom_com.key
And then you will obtain an A at https://www.ssllabs.com/ssltest/
You need to combine 1,2, and 3 into one chain certificate (in the correct order) and upload them in the chain certificate field, the key goes in the key field, and the myApp.crt goes in the certificate field.
I had a similar problem, and after some back and forth emails with the Certificate issuer, what helped me was to combine my site certificate with the Certificate chain into one file, and uploading it into the "SSL Certificate" field in OpenShift. I left the "SSL Certificate Chain" field blank, but of course I uploaded my public key in the "Certificate Private Key" field.
On Debian, using GitLab, I ran into issues with my self-signed certificate.
Reading through the code after a lot of searching on the Internet (I guess, it's the last resort, FOSS is helpful), I found the following lines in gitlab-shell/lib/gitlab_net.rb which left me... perplexed.
if config.http_settings['self_signed_cert']
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
end
Most Stack Overflow responses about the diverse issues I've had until now have led me to believe that VERIFY_NONE, as you'd expect, doesn't verify anything. VERIFY_PEER seems, based on my reading, to be the correct setting for self-signed.
As I read it, it feels like taking steps to secure my connection using a certificate, and then just deciding to not use it? Is it a bug, or am I misreading the source?
gitlab-shell (on the GitLab server) has to communicate to the GitLab instance through an HTTPS or SSH URL API.
If it is a self-signed certificate, it doesn't want any error/warning when trying to access those GitLab URLs, hence the SSL::VERIFY_NONE.
But, that same certificate is also used by clients (outside of the GitLab server), using those same GitLab HTTPS URLs from their browser.
For them, the self-signed certificate is useful, provided they install it in their browser keystore.
For those transactions (clients to GitLab), the certificate will be "verified".
The OP Kheldar point's out in Mislav's post:
OpenSSL expects to find each certificate in a file named by the certificate subject’s hashed name, plus a number extension that starts with 0.
That means you can’t just drop My_Awesome_CA_Cert.pem in the directory and expect it to be picked up automatically.
However, OpenSSL ships with a utility called c_rehash which you can invoke on a directory to have all certificates indexed with appropriately named symlinks.
(See for instance OpenSSL Verify location)
cd /some/where/certs
c_rehash .
I'm completely new to anything Secure Socket Layer related up until yesterday evening and today. I need to get a self-signed certificate to proceed with an app registration process so that I can implement OAuth in an app I'm writint. I went through a nice tutorial about how to generate certificates here. I'm an ubuntu user, if you didn't click the link to figure that out. I've been trying to generate a self-signed 1024 bit RSA key encoded x.509 certificate in PEM format. After setting up the configuration and doing everything as is on the tutorial (of course with the exception of specifying the environment-related data to my own environment). The commands to generate a new certificate and key after going through the configuration are:
forces SSL to look for configuration file in alternate location (the server configuration file):
export OPENSSL_CONF=~/myCA/exampleserver.cnf
Generate the certificate and key:
openssl req -newkey rsa:1024 -keyout tempkey.pem -keyform PEM -out tempreq.pem -outform PEM
Following those two commands the following is displayed:
Generating a 1024 bit RSA private key
...++++++
...............++++++
writing new private key to 'tempkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
I enter my pass phrase and the error I continually get is:
problems making Certificate Request
3074111688:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:a_object.c:109:
3074111688:error:0B083077:x509 certificate routines:X509_NAME_ENTRY_create_by_txt:invalid field name:x509name.c:285:name=organizationUnitName
I ran into a similar problem while following the same tutorial that you mentioned. In my case, the error was:
problems making Certificate Request
140098671105696:error:0D07A097:asn1 encoding routines:ASN1_mbstring_ncopy:string too long:a_mbstr.c:154:maxsize=2
So I figured out that I've written some string which should have been 2 characters long (maxsize=2), but happened way longer. I returned back to my config file and quickly found that I've wrote the long name of the country, instead of the 2-character code. This solved my problem.
not really familiar with the process but, it appears "invalid field name:x509name.c:285:name=organizationUnitName" means your Organization Unit Name is invalid.
According to digicert.com: The Organizational Unit is whichever branch of your company is ordering the certificate such as accounting, marketing, etc.
it depends on what is in your conf file, the openssl ca tool looks for sections in the file, those sections look for other sections, some of the section names are mandatory and some of the name/value pairs in sections are mandatory.. it's quite a big configuration space offered by this file
The error you mention comes up when openssl doesnt recognise a name inside a section in different scenarios, e.g. i've seen it when I was adding a custom oid for an end-entity cert, and also when customising contents of a ca cert.
if you post your configuration file and what you expect in the resulting ceritifcate then we can help. Also can you say what you intend to use the certificate for (e.g. secure a client session on a production webservice or something else)
I had the same problem, had C=USA instead of C=US
I had a similar issue. I followed the advice from GitHub using the countryName_default parameter. It seems like this parameter does not exist on my openssh.exe, contrary to the advice on GitHub.
Once I removed any xxx_default parameters from the [ req_distinguished_name ] section of the SSL xxx.conf file, the creation of the certificate succeeded.
This is working on Windows 10.