I'm using the excellent Charles proxy to make web debugging easier. I'm using it's SSL proxying abilities, and have installed the generic CA Certificate that it comes bundled with. While this works, it's insecure because as long as my browser trusts this certificate, I am vulnerable to a MIM attack.
I'm trying to use OpenSSL to create a "Custom CA Certificate" since Charles allows to fix this. These are the steps I'm following:
NAME=daaku-ca
openssl genrsa -out $NAME.key 1024
openssl req -new -key $NAME.key -out $NAME.csr
openssl x509 -days 3650 -signkey $NAME.key -in $NAME.csr -req -out $NAME.crt
openssl pkcs12 -export -out $NAME.pfx -inkey $NAME.key -in $NAME.crt
Following these steps I end up with a Self signed root certificate $NAME.crt that I successfully imported into my Mac OS X keychain. And while the $NAME.pfx in Charles works and is being correctly used if I enter a password for it, it does not work if there's no password.
My question is how do I generate a certificate that works in Charles and does not need a password.
I blogged about how to use a Custom SSL Certificate with Charles and in the last section I address the problem of having to type in the password every time Charles launches.
http://codeblog.shape.dk/blog/2014/01/06/custom-ssl-certificate-with-charles-web-proxy/
Since Charles 3.10 came out this is not an issue anymore since each installation generates its own certificate. So even if you trust the Charles-generated Certificate, you won't be susceptible to MIM attacks by other Charles users.
Per version 3.10 release notes:
Version 3.10 21 March 2015
Major new features, improvements and bug fixes.
SSL changes
SSL certificate root certificate change to generate a unique
certificate for each installation of Charles (see SSL Proxying in the
Help menu) SSL Proxying now has its own settings menu item in the
Proxy menu Please note that these changes will affect the way you
currently use Charles for SSL Proxying. You will need to install and
trust a new certificate, which will be automatically generated for
you. You can install that certificate on your computer using the
options in the Help menu, under SSL Proxying. You can also export the
certificate, to send to other systems, or browse to download the
certificate to install on mobile devices such as iPhones.
Related
I'm experimenting with Spring Boot to create a WebApp.
In order to create a SSL certificate I issue the following command:
keytool -alias devssl -keystore devssl.p12 -genkeypair -keyalg RSA -sigalg SHA256withRSA /
-keysize 2048 -storetype PKCS12 -validity 365 -dname "CN=Frankie, OU=Frankie O=Frankie, /
L=City, S=State, C=UK" -ext SAN=DNS:localhost,DNS:blueye,IP:127.0.0.1,IP:10.1.1.2"
Which from what I can understand means that such certificate will be valid for the following addresses:
localhost
blueye
127.0.0.1
10.1.1.2
The certificate is very easy to install on Spring:
server.ssl.key-store-type=PKCS12
server.ssl.key-store=devssl.p12
server.ssl.key-store-password=password
server.ssl.key-alias=devssl
security.require-ssl=true
After I install the certificate under Trusted Root Certification Authorities in Windows it also works great.
I just can't get it to work under iOS.
I email myself the certificate.
Install it on the iPhone.
But I always get the "this connection is not private".
Any idea how to make this work on iOS?
I was pushing on this trying to get iOS to accept a self-signed certificate as the single source of truth. I got to work around it by issuing a proper personal Certificate Authority. Making iOS trust that authority. And then signing the website with a certificate validated by that authority.
I will describe the needed commands as they may save someone a couple of hours. The following is a "birds eye" of what we'll do.
AUTHORITY - this will act as the source of trust for all certificates you sign. You will have to install the Authority on every single machine/phone you'll want with custom certificates
Generate a private key for a Certificate Authority (CA)
Generate a Certificate for the Certificate Authority (CA)
Install Certificate Authority on Windows
Install Certificate Authority on iOS
CLIENT - we can issue private keys for all our projects inside our network. Those private keys will be validated by our own generated and installed authority.
Generate a private key for the client
Generate a Certificate Sign Request (CSR)
Have CA sign the CSR thus generating the client Certificate
Merge the client certificate and the CA certificate into a pkcs12 file which is read by Spring
Now for the actual commands:
Generate a private key, we'll also use an identical command to generate one for the client:
openssl genrsa -des3 -out myCA.key 2048
Generate a certificate for your Certificate Authority. You'll be asked several questions, none of them really matter, they will only serve to identify your certificate to yourself.
openssl req -x509 -new -nodes -key myCA.key -sha256 -days 1825 -out myCA.pem
openssl req -x509 -new -nodes -key myCA.key -sha256 -days 1825 -out myCA.crt
You now have three files. The myCA.key (private key) and the myCA.pem and myCA.crt which are the certificate file for your certificate authority.
Install on Windows:
Click the myCA.crt file on Windows and follow screen instructions. Then click Start -> Run -> `` certmgr.msc`. It will open the Windows Certificate Manager. You will find the certificate you installed under "Intermediate Certification Authorities". You'll want to drag that file to "Trusted Root Certification Authorities".
Install on iOS:
Email the myCA.pem file to yourself. Open the email on iOS using the Apple Mail App. Follow the instructions and certificate will be installed. To uninstall you can go to Settings -> General -> Profile. After proper installation iOS requires a second step for you to trust the certificate, you must go to Settings -> General -> About -> Certificate Trust Settings and Enable Full Trust For Root Certificate.
You now have a local CA (Certificate Authority) installed on both your Windows machine and your iOS phone. Lets create a website certificate.
Generate a private key for the website.
openssl genrsa -des3 -out myWebsite.key 2048
Generate a CSR (Certificate Sign Request):
openssl req -new -key myWebSite.key -out myWebsite.csr
Now that we have the website key and the certificate sign request we need to create a config file that openssl will use to generate our website certificate. Create a file called myWebsite.ext with the following info. The only thing you must make sure is the alt names. You can have both IP's and DNS. Be sure to enter all the alternatives that your site will use.
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = mywebsite
DNS.3 = mywebsite.local
IP.1 = 10.1.1.3
IP.2 = 127.0.0.1
Now we'll use the CA certificate and private key together with the CSR (Certificate Sign Request) and the config file to generate a proper certificate for the website. Since iOS 13 Apple only allows a max of 825 days on certificates so that's what we'll use.
openssl x509 -req -in myWebsite.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial -out myWebsite.crt -days 825 -sha256 -extfile myWebsite.ext
You'll now have the following files:
myCA.key - certificate authority private key
myCA.pem - certificate authority certificate pem format
myCA.crt - certificate authority certificate crt format
myWebsite.key - website private key
myWebsite.csr - website certificate sign request
myWebsite.ext - website config file for openssl sign request
myWebsite.crt - website certificate crt format
The only thing missing is to convert the myWebsite.crt to p12 format which we can do with the following command:
openssl pkcs12 -export -in myCA.crt -inkey myCA.key -in myWebsite.crt -inkey myWebsite.key -name myWebsite -out myWebsite.p12
Now, to make Spring Boot use this certificate just open application.properties file and make sure it has these lines:
server.ssl.key-store-type=PKCS12
# The path to the keystore containing the certificate, place it src/main/resources
server.ssl.key-store=classpath:myWebsite.p12
# The password used to generate the certificate
server.ssl.key-store-password=PASSWORD-USED
# The alias mapped to the certificate (the -name myWebsite on the last command)
server.ssl.key-alias=myWebsite
# force SSL
security.require-ssl=true
And there you have it. A dev or internal project with proper SSL validation. Hope this saves someone some time.
It looks like you were having trouble creating the certificates correctly, for a great guide on how to do that, check out:
https://jamielinux.com/docs/openssl-certificate-authority/introduction.html
If you follow it exactly, and know what your DNS name is, and what cipher you are using, you shouldn't have any problems. I provide my configuration files for making the certificates, along with a project that helps with sockets, below:
https://github.com/eamonwhiter73/IOSObjCWebSockets
I've been trying to create a self-signed certificate for a public ip that I created in Azure to host a Node-Red instance and it seems that in Node-Red it needs PEM files to enable HTTPS.
I've have tried to create these files using OPENSSL.
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
However when I try to access it, it says that the certificate is invalid.
Are there any other ways to make a self-signed certificate ??
The error is because your browser doesn't know to trust the certificate because it is not signed by one of it's trusted Certificate Authorities.
You have 3 options
If you look closely on the page there will be a way to ignore the error and continue to load the page.
You can import the certificate (since it is self signed) into the browers list of trusted certificates (if you tick the right box in option 1 this will basically happen automatically)
Rather than use a self signed certificate (Which really shouldn't be used for anything that is attached to a public IP address these days) you should use a real certificate from LetsEncrypt. These are free and already trusted by your browser.
So, we were trying to setup communication with the apple MFi server for staging.
Have followed the steps as per the documentation which state that the license server should be trusted (DigiCert certificate used for the same) and that the client certificate must be provided to apple in order to establish a secure tunnel.
The client certificates (.pem files) we are trying with were generated a few months back but are still valid. The .pem doesn't seem to authorize a machine but rather a company account, correct me if I'm wrong here. (So it should work if the csr for the pem files was not generated from the licensee server?)
Also, while trying to create a new certificate get a MAX_REQUEST error. Got conflicting information about whether there can be more than to certificates active for the staging profile for an account.
Tried through Postman as well as .NET
var handler = new HttpClientHandler();
handler.ClientCertificateOptions = ClientCertificateOption.Manual;
handler.SslProtocols = SslProtocols.Tls | SslProtocols.Tls11 | SslProtocols.Tls12;
handler.ClientCertificates.Add(new X509Certificate("Certificate.pem"));
var httpClient = new HttpClient(handler)
// Tried with and without the user name
httpClient.DefaultRequestHeaders.TryAddWithoutValidation("User-Agent",
"Company Name/Client Name/Client Version");
var result = httpClient.GetAsync(StagingURL).Result;
Always get a 401, Unauthorized Access error from the Apple Server. Wanted to know what the cause might be.
Thanks in advance!
Apparently, indeed only two staging certificates can be active at one time.
As for the certificate issue, .pem parsing might have been an issue but did not work with a .cer file either. The .pem only had the public key in it, needed to create a .p12 with the .pem and the private key that was used for generating the .csr.
If you are on a mac you should get it right away, on Windows, I had .jks file and had to create a .key file out of it:
keytool -importkeystore -srckeystore mykey.jks -destkeystore keystore.p12 -deststoretype PKCS12
openssl pkcs12 -in keystore.p12 -nocerts -nodes -out mykey.key
And then wrap the two in a .p12
openssl pkcs12 -export -in mycert.pem -inkey mykey.key -out myp12.p12
Firefox upgraded to version 33.0 this morning. Since then, I cannot load a specific local application over HTTPS -- note that it uses a self-signed certificate. It displays the following error message:
The key does not support the requested operation. (Error code: sec_error_invalid_key)
I cannot see anything in Firebug. I restarted Firefox in safe mode, to make sure no add-on was the problem. I also cleaned my cache and cookies. The same application opens fine with Chrome, and Firefox can open other applications that use HTTPS with a self-signed certificate.
Any idea how I could troubleshoot this issue?
Edit: Mozilla has made several important changes to security in Firefox 33.0. Details can be found here.
In my particular situation, the self-signed certificate was blocked because it was deemed too weak:
RSA 512, 1000 and 1023-bit certificates are now blocked by Firefox since they are not sufficient for security. Most certificates currently being issued should have a 2048-bit key length.
I have encountered the same problem after upgrading to Firefox 33 with Tomato router. The key length is a problem here.
Tomato generates 512 bit long RSA key by default. However, Firefox 33 requires minimum 1024 bit key.
I had to manually generate a longer key in Tomato.
I did that following way:
Log in using ssh to the router.
cd /tmp
cp /usr/sbin/gencert.sh .
chmod +w gencert.sh
Edit the gencert.sh file you copied and change the following line:
openssl req -new -out /tmp/cert.csr -config openssl.config -keyout /tmp/privkey.pem -newkey rsa:512 -passout pass:password
into:
openssl req -new -out /tmp/cert.csr -config openssl.config -keyout /tmp/privkey.pem -newkey rsa:1024 -passout pass:password
./gencert.sh $(date +%s)
nvram unset https_crt_file
nvram commit
service httpd restart
Now httpd will use the new certificate. If you have "Save in NVRAM" checkbox enabled it will be saved in NVRAM and survive router reboot.
Do not check "Regenerate" checkbox, because automatically regenerated certificates are still 512 bit long.
If you remove your certificate from NVRAM, you must repeat procedure described above.
Firefox 34 and newer:
Starting from Firefox 34 you need to additionally enable SSL 3.0 support in Firefox configuration:
Enter about:config address in the URL bar.
Set the following options to 0:
security.tls.version.fallback-limit
security.tls.version.min
For Webmin:
I created a new ssl certificate and now it is working with FF 33.
Webmin -> Webmin Configuration -> SSL Encryption -> Self-Signed Certificate
turned off Hardware acceleration in the Options> Advanced > General Tab
Problem cleared up
For various reasons I have created a simple HTTP server, and added SSL support via OpenSSL. I'm using self-signed certificates. IE, Firefox and Chrome happily load content as long as I add the CA to the trusted root CAs.
However, wget (even when using the --no-check-certificate flag) reports:
OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
If I run the OpenSSL client against my server using:
openssl s_client -connect dnvista:82 -debug
I get back:
verify error:num=19:self signed certificate in certificate chain
verify return:0
and then
5852:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:.\ssl\s3_pkt.c:1060:SSL alert number 40
5852:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:.\ssl\s23_lib.c:188:
Do wget and the OpenSSL client simply not work with self-signed certificates?
UPDATE:
For anyone that comes along later, adding this code helped with the OpenSSL client and Firefox:
EC_KEY *ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
SSL_CTX_set_tmp_ecdh(ctx, ecdh);
EC_KEY_free(ecdh);
I checked the man page of wget, and --no-check-certificate only seems to affect the server certificate. You need to specify your self-signed certificate as a valid CA certificate locally.
To do this, specify the certificate as --ca-certificate=... in wget and -CAfile in the s_client case.
You can also install trusted root CA certificates into OpenSSL in one of a number of ways:
Put your CA certificate in /etc/pki/tls/certs or equivalent directory, then create a link based on the certificate hash. See http://gagravarr.org/writing/openssl-certs/others.shtml#ca-openssl for details.
Append your CA certificate to /etc/pki/tls/certs/ca-bundle.crt, /etc/pki/tls/cert.pem, or equivalent CA bundle.