I’m currently using an SSL certificate on a MAMP server that I made myself via OpenSSL. I’m running the MAMP server on an Apple Mac that’s running Monterey 12.4. I have no problems running the website that I’ve created via the MAMP server with the SSL certificate I created on any web browser except Mozilla Firefox. I’ve tested every other browser and my website runs without any issues whatsoever.
On Mozilla Firefox, I’m getting an error message that indicates a security risk, and at the bottom of the error message reads “SSL_ERROR_BAD_CERT_DOMAIN”. When I type www. In front of the website URL, for whatever reason, the site runs without any issues on Mozilla Firefox.
Could this issue on Mozilla Firefox be resolved if I created a 2 way SSL certificate that included my website's name with www. in it? If so, how could I go about creating a 2 way SSL certificate? If anyone knows how to solve this issue, I’d greatly appreciate you sharing your knowledge with me.
Listed below is the method I took to create an SSL certificate via OpenSSL. If any step in this is incorrect or a further step needs to be added, I’d much appreciate sharing the correct steps with me.
- openssl genrsa -des3 -out local-ca.key 2048
- openssl req -x509 -new -nodes -key local-ca.key -sha256 -days 365 -out local-ca.pem
Country Name (2 letter code) []:
State or Province Name (full name) []:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Common Name (eg, fully qualified host name) []: www.mywebsite.com
Email Address []:
- openssl genrsa -out server.key 2048
- openssl req -new -key server.key -out server.csr
Country Name (2 letter code) []:
State or Province Name (full name) []:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Common Name (eg, fully qualified host name) []: www.mywebsite.com
Email Address []:
- openssl x509 -req -in server.csr -CA local-ca.pem -CAkey local-ca.key -CAcreateserial -out server.crt -days 365 -sha256 -extfile v3.ext
The contents of the vs.ext file:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = www.mywebsite.com
Related
I've faced the problem with SSL connection to MongoDB (SSLContextService processors).
all certificates I've generated (Root, Server and Client). Server and Client certificates I've signed with my root certificate. Since my MongoDB-Sever has more then one IP-Address, I've include all IP-Addresses in the server certificate.
MongoDB is also configured for ssl connections (tls), the old version of tls (1.1, 1.2) are not disabled in MongoDB.
SSL-Connection with mongo-shell works without problems. I've also checked everything with openssl s_client and connection was there and also worked properly.
For Apache NiFi I've created keystore (PKCS12)
openssl pkcs12 -export -name client -in client.crt -inkey client.key -certfile ca.crt -out client.p12
and also truststore with server certitiface
openssl pkcs12 -export -name server -in server.crt -inkey server.key -out server.p12
and I've also tried
openssl pkcs12 -export -name server -in server.crt -inkey server.key -certfile ca.crt -out server.p12
ca.crt is my root certificate. client.crt and server.crt were sigend with this ca.crt.
I've used both services in NiFi:
StandardSSLContextService and StandardRestrictedSSLContextService. In the parameter Keystore I've put client.p12 and in truststore parameter server.p12. Both types PKSC12. TLS protocoll just TLS.
But anyway I get an error "PKIX path building failed".
I'm not sure what I've missed, but may be someone had such problem already.
Thanks in advance.
P.S. forgotten:
If I set in MongoDBControllerService parameter "Client Auth" to "NONE" then it works.
PKIX path building errors mean that NiFi cannot construct the trusted "path" between the certificate that is presented by the other endpoint (in this case MongoDB) and any of the certificates which are loaded in the respective truststore to identify trusted certificates.
If I am watching my niece tells me she's allowed to have all the candy she wants, I am not likely to agree. However, if she has a signed note from her parent confirming that, she gets candy. If she has a note signed by herself in crayon, not so much.
The likely solution is to concatenate the root public certificate and the node certificate into a single file (literally just cat server.pem ca.pem > combined_server.pem; make sure the node cert is first). That command assumes the certificate files are in PEM-encoded ASCII format (i.e. starts with -----BEGIN CERTIFICATE-----) and I prefer using .pem for the extension here, though .crt files can also contain this data. You can then verify that the chain is correct with
openssl verify -verbose -purpose sslserver -CAfile ca.pem combined_server.pem
For consistency, I'd repeat the process with the client cert and CA as well (use -purpose sslclient in the verification command). Then regenerate the PKCS12 keystore & truststore and load them into NiFi.
I am slightly confused by the fact that you say disabling client authentication in NiFi allows this to work, as NiFi should be acting as the client, and clients don't get to determine the client authentication level (the setting is literally ignored when acting as a client). It should only matter if NiFi is somehow acting as the server and MongoDB is the client. What version of NiFi and MongoDB are you using?
NiFi uses its own truststore which is either jks or pfx (p12) format, not concatenated pem files and not system files under /etc/pki/ca-trust/. As far as I can tell, you are not allowed to pass the tlsCAFile url parameter from a nifi processor which is confusing.
I tried to use client certificate for authentication using swift XMPP client but not able to select certificate, although I already import certificate in Window client certificate.
Got below message from the client, click ok to continue exit the window certificate dialog.
You need to install certificate first in the OS then the list will show installed certificate in the system.
To install certificate create pfx certificate formate and double click to install the certificate.
To create PFX
openssl pkcs12 -export -out my_certs.pfx -inkey example.com.key -in example.bundle.pem -certfile ca.pem
I am trying to make REST calls to server from a client.
Server Side
I am using Flask as web server. I have generated the certificate(cert.pem) and public key(key.pem) using the following command.
openssl req -x509 -newkey rsa:4096 -nodes -out cert.pem -keyout key.pem -days 365
Following is the server side code.
from flask import Flask
from flask_restful import Resource, Api
app = Flask(__name__)
api = Api(app)
class HelloWorld(Resource):
def get(self):
return {'hello': 'world'}
#app.route('/someroute/<arg1>,<arg2>', methods=['GET'])
def fn1(arg1,arg2):
res = fn2(arg1, arg2)
return str(res)
def fn2(un,pwd):
#Do something and return a number
return num
if __name__ == '__main__':
context = ('cert.pem', 'key.pem')
app.run(host="ip", port=port1, debug=True, ssl_context=context)
Client Side
I have a flask application from which I need to make REST calls to the above server. Following is the code I am using to do so.
import requests
# Below is the part of a function which gets called upon hitting a route in Flask.
ret = requests.get("https://<ip>:<port1>/<someroute>/arg1,arg2", verify=True)
print ret.text
This is throwing the following error.
requests.exceptions.SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
This error is expected as the certificate is not known to the client. Everything is working perfectly fine if I skip the certificate verification (verify=False).
How do I make the client trust this unknown server SSL certificate? I have seen solutions where I need to use Nginx on the client side. Can we not do some changes on flask(client side) itself to make it trust my server? If yes, what is that exact change I should be making in Flask? Also, suggest if urllib is better than requests.
UPDATE 1
I have another query here. From above, I understood that requests.get verifies the certificate every time we make a REST call (Please correct me if I am wrong). But, this looks like an extra load. Can we not have an encrypted connected established in the beginning and exchange the data by encrypting it with a private key? So, how to implement the beginning part - Send private key by encrypting it with the public key to the server and then start exchanging data by encrypting the data with the private key.
OC (original comment):
Server Side
I am using Flask as web server. I have generated the certificate(cert.pem) and public key(key.pem) using the following command.
openssl req -x509 -newkey rsa:4096 -nodes -out cert.pem -keyout key.pem -days 36
If you read man req it says,
-out filename
This specifies the output filename to write to or standard output by default.
-keyout filename
This gives the filename to write the newly created private key to. If this option is not specified then the filename present in the configuration file is used.
Here, cert.pem could be referred to as the public certificate and key.pem really is your private key (Keep it safe and well, private). FTFY.
OC (original comment):
This error is expected as the certificate is not known to the client. Everything is working perfectly fine if I skip the certificate verification (verify=False).
How do I make the client trust this unknown server SSL certificate? I have seen solutions where I need to use Nginx on the client side. Can we not do some changes on flask(client side) itself to make it trust my server? If yes, what is that exact change I should be making in Flask? Also, suggest if urllib is better than requests.
I'll answer this backwards, but first a little background. I found these links really useful to understand - on a high level - how the SSL/TLS handshake happens and how authentication is carried out
IBM: An overview of the SSL or TLS handshake
IBM: How SSL and TLS provide authentication
Now, coming back to your question,
requests > urllib (Personal opinion, but requests does have a good support and is mature - not implying that urllib isn't)
It looks like you want to do server authentication only, for that your client needs the server's public certificate. From How SSL and TLS provide authentication:
The certificates required are as follows, where CA X issues the certificate to the SSL or TLS client, and CA Y issues the certificate to the SSL or TLS server:
For server authentication only, the SSL or TLS server needs:
The personal certificate issued to the server by CA Y
The server's private key
and the SSL or TLS client needs:
The CA certificate for CA Y
Use it in requests.get referring this from requests, which says,
You can pass verify the path to a CA_BUNDLE file or directory with certificates of trusted CAs:
requests.get('https://github.com', verify='/path/to/certfile')
Once you do that and have good certificates, it should work.
NOTE: The openssl command in the OC does not show any subject for the key/cert pair, this would still fail cert verification, refer documentation that shows how to generate self-signed certs. There's a requirement to provide SANs (SubjectAltNames) so providing just a CommonName (CN) in the subject won't future proof your process.
EDIT:
The CA talk in the IBM document can be confusing, but since this is a self-signed cert, you don't have to worry about this, just think of it as your Flask server being the SSL/TLS server, and any client of that server can do server verification using server's public key.
OC (original comment):
From above, I understood that requests.get verifies the certificate every time we make a REST call (Please correct me if I am wrong). But, this looks like an extra load.
That's true. It would perform verification each time. To avoid that you can use requests.Session() as mentioned in requests SSL Cert Verification
OC (original comment):
Can we not have an encrypted connected established in the beginning and exchange the data by encrypting it with a private key? So, how to implement the beginning part - Send private key by encrypting it with the public key to the server and then start exchanging data by encrypting the data with the private key.
This is explained really well in the IBM docs listed
Is the AuthorityInfoAccess field mandatory in x509v3? I have some certificates, and I'm trying to do OCSP verification, but they don't seem to have this field when I do
openssl x509 -in file.cer -inform DER -text -noout
I was wondering if it's not in that output does that mean it's not there?
Neither extension is mandatory. All they are technically optional. But some applications may require the presence of particular extensions.
For example, for CA certificate it is required to have a Basic Constraints and KeyUsage extensions. Otherwise, the certificate would not be recognized as CA certificate.
In addition, when creating X.509v3 certificates, it is a good practice to include Subject Key Identifier to simplify certificate binding in the chain by using key match.
There are two cases when Authority Information Access (and CRL Distribution Points) should not be presented: in any self-signed certificates and OCSP signing certificates.
As you are talking about OCSP certificate, there is no practical need in this extension, because all required information is elsewhere. For example, if target certificate and its OCSP response are signed by the same CA, existing target certificate's chain is reused. If OCSP uses delegated OCSP signing certificate, then delegated certificate's chain is included in the OCSP response directly.
In practice, badly generated certificates doesn't contain Authority Information Access extension as well.
Is there a way to create a self signed certificate from your own ios application?
Is this more what you're after?
How to use NSURLConnection to connect with SSL for an untrusted cert?
Certificate configuration:
You have to install the Self Signed Certificate or CA on the device in order for the device to trust it
then only device trusts the SSL connection.
In the case of installing self signed certificate make sure domain name of the URL is same as Common name of certificate.
If there is no domain name then IP address is fine.
Certificate installation:
You can just host it on the web server and try to access it from safari then iOS will prompt for the certificate installation in the iOS Device
Certificate Creation:
Here is the way to create self signed certificate so that you can fill all the details and host in web server.
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 1001 -nodes
(Pay attention while entering the value for Common Name)