I have generated my own CA files - cacert.pem, careq.pem, cakey.pem.
The internet explained that I definitely shouldn't use PKCS#12 (.p12) as it exposes my private key and that browsers like .der format (which is binary format for pem?!). This just enhances the confusion.
From my point of understanding this http://www.cacert.org/certs/root.txt is a .pem, right? And if I cut everything out, except the "PEM armor" I get a .crt?
So the question is: how do I safely (!) distribute this root certificate for installations on client workstations (.pem, .crt, etc)?
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.
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.
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.
How do you transfer a Godaddy SSL certificate to the Google Cloud Platform?
I am trying to setup an HTTPS load balancer on Google Cloud. I have an SSL certificate from Godaddy, but I'm not sure how to input it into Google Cloud. Google has a form to enter a public key, a certificate chain, and a private key all in .pem format (see screenshot below). Godaddy provides me with three files: (1) a file called #####.crt, (2) a file called gd_bundle-g2-g1.crt, and (3) an RSA private key.
I've seen other SO questions on converting .crt to .pem, but I'm not sure what what to do with the .pem files when I have them or which of these three files go into which box in the GCE console below.
This happened to me, good to know I'm not alone!
Plain and simple answer: Godaddy will give you a certificate file and a bundle file. They all come already on PEM format (as long as it says BEGIN CERTIFICATE you know it's PEM).
Copy and paste the contents of the #####.crt file on the "Public key certificate" field, it should display the correct information on the right side of the field.
Copy and paste the contents of the certificate bundle on the "Certificate chain". This file usually has 3 certificates on it.
Finally, copy and paste the contents of your private key on the last field.
Double check that your certificate is working correctly on both desktop and mobile. If it works on desktop but not mobile try again, it means you made a mistake filling the "Certificate chain" field.
Hope this helps!
AFAIK you dont need to convert the file to PEM, quite sure it is already a PEM file, to be sure do file gd_bundle-g2-g1.crt or file #####.crt the output should be something like PEM certificate, you copy you private key into the "Private Key", you take .crt file and copy to the "Public key Certificate" once you do this some information will appear on the right side of these box, in my case, I copied the same .crt file on the "Certificate Chain".
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.