Is there a way to create a self signed certificate to Azure using openssl for enabling secured layer? - https

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.

Related

Securing minifi c++ agent against remote NIFI

I have a remote 3 node secure NIFI server to which I want to send some data via MINIFI C++ agent. I am trying to understand the mechanics of generating and signing certificates for MINIFI (client) but I am not able to find detailed documentation.
I see the below configs:
#nifi.security.need.ClientAuth=
#nifi.security.client.certificate=
#nifi.security.client.private.key=
#nifi.security.client.pass.phrase=
#nifi.security.client.ca.certificate=
but how do I generate a client.pem and sign it?
EDIT:
This is what I tried to do (self-sign), but this fails with:
[2020-08-14 07:19:08.872] [org::apache::nifi::minifi::utils::HTTPClient] [error] curl_easy_perform() failed SSL connect error
[2020-08-14 07:19:08.872] [org::apache::nifi::minifi::RemoteProcessorGroupPort] [error] ProcessGroup::refreshRemoteSite2SiteInfo -- curl_easy_perform() failed
cd $HOME
openssl req -new -newkey rsa:4096 -nodes -keyout machine.key -out machine.csr
openssl x509 -req -sha256 -days 365 -in machine.csr -signkey machine.key -out machine.pem
###
Downloaded the public certificate from the server into ---> $HOME/server.crt
nifi.security.need.ClientAuth=true
nifi.security.client.certificate=$HOME/machine.pem
nifi.security.client.private.key=$HOME/machine.key
nifi.security.client.pass.phrase=password
nifi.security.client.ca.certificate=$HOME/server.crt
There are many ways to generate an X.509 certificate and sign it (openssl, TinyCert, Let's Encrypt, NiFi TLS Toolkit, etc.). The important requirement is that the certificate is either explicitly trusted (the public certificate is imported into the NiFi truststore) or implicitly trusted (any of the public certificates in the signing chain are present in the NiFi truststore).
One approach is to follow the walkthrough for deploying a secure NiFi cluster and use the TLS Toolkit to generate a client keystore, then export the certificate and key from that keystore to PEM format using these commands.

Spring Boot SSL webapp iOS testing

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

Apple MFi - Homekit Software Authentication

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

How can I specify an E-Mail address when signing a binary file?

I'm using signtool to apply a digital signature to various .exe/.dll files. However, viewing the signed files in Windows Explorer shows that no E-Mail address is set, much like in this screenshot (I'm by no means affiliated with "Paramount Software UK Ltd." -- this screenshots is just the first result I found via Google):
However, I also saw other screenshots showing that it's somehow possible to define an E-Mail address (even if it's a bogus one, like in this case):
Is it possible to set this E-mail address via signtool, or is it actually a property of the certificate itself (i.e. it needs to be specified when purchasing a certificate)?
The email property it's extracted from emailAddress in a subject distinguished name field of your certificate.
You can make a test using openssl to generate a selfsigned certificate (then you can generate a CSR with an emailAddress and send to the certificate authority to generate a valid end-entity certificate). To test it you can do the follow steps:
Generate self-signed certificate using the follow openssl command
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
Then you will be asked to enter the follow parameters (all for a subject of the certificate):
To avoid this prompt you can directly specify the subject in the previous command using -subj as follow:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -subj "/C=ES/ST=58/L=Barcelona/O=yourOrgName/OU=yourDept/CN=yourAppName/emailAddress=myEmail#test.com"
Now you can generate a p12 (or pfx) from the generated key and cert using the follow command:
openssl pkcs12 -export -out myTestWithMail.pfx -inkey key.pem -in cert.pem
Now you have a p12 (myTestWithMail.pfx), that you can use to sign an exe or dll using the follow signtool command. For example I sign notepad++.exe (as in the examples you link in your question):
signtool.exe sign /f C:\Users\Albert\myTestWithMail.pfx /p 1234 "C:\Program Files (x86)\Notepad++\notepad++.exe"
Note that /f is for the path of your signing key, and /p is the password for your key.
Now you can see the email in the file you sign:
So finally if you need a certificate from a certificate authority you have to generate the CSR specifying emailAddress for example using openssl command:
openssl req -new -newkey rsa:2048 -nodes -out yourAppName.csr -keyout yourAppName.key -subj "/C=ES/ST=58/L=Barcelona/O=yourOrgName/OU=yourDept/CN=yourAppName/emailAddress=myEmail#test.com"
Or alternatively without specifying -subj parameter and enter the correct values for subject distinguished name when are prompted:
openssl req -new -newkey rsa:2048 -nodes -out yourAppName.csr -keyout yourAppName.key
Hope this helps,
Short answer: Yes, the e-mail address is part of the certificate and no, you cannot specify it when signing a binary file.
Long answer: #albciff pointed out how to generate a certificate which has an email address associated with it but it seems you're out of luck in case you bought the certificate from Thawte; my colleague asked this exact question to the technical support of our certificate provider (Thawte) which replied:
When enrolling for a Code Signing certificate the email address used is not part of the validation process. Unfortunately, because the email is not part of the validation process it will not be included in the properties of the signed code.
Furthermore, tech support referred us to
this article in the 'Thawte Knowledge Center' which explains:
The e-mail address always appears as "not available" when viewing the properties of signed code. This is because the certificate validates the organization but requires no information about the e-mail address of the organization. Thus, we have validated the organization, but have not validated the e-mail. This in no way lessens the value or usefulness of your ID.
So not only is the email address part of the certificate, whether you can associate an email address with the certificate also depends on who issued the certificate.

Custom CA Certificate in Charles without a password

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.

Resources