I am in step 3 of AWS OTA documentation https://docs.aws.amazon.com/freertos/latest/userguide/ota-code-sign-cert-esp.html
I am able to do the first two steps but not able to make the certificate:
openssl req -new -x509 -config cert_config.txt -extensions my_exts -nodes -days 365 -key ecdsasigner.key -out ecdsasigner.crt
I get the following error:
Can't open cert_config.txt for reading, No such file or directory
25968:error:02001002:system library:fopen:No such file or directory:../openssl-1.1.1k/crypto/bio/bss_file.c:69:fopen('cert_config.txt','r')
25968:error:2006D080:BIO routines:BIO_new_file:no such file:../openssl-1.1.1k/crypto/bio/bss_file.c:76:
I have tried:
installing another version of ssl instead of using git bash but I ran into the same issue
I have tried elevated privleges as adminstrator
I have tried the full path to "cert_config.txt" with or without double quotations and to no avail
Any help is appreciated
I am an idiot, if I look at the full file it's cert_config.txt.txt
Try ./cert_config.txt in the parameter.
I'm trying to put all the different certificates in a single .pfx (PKCS12) file. I am able to import all the PrivateKeyEntry(s) in a master pfx file (also I verified the entries using keytool command - output snippet -
alias1, Sep 9, 2020,PrivateKeyEntry,
Certificate fingerprint (SHA1):<XX:YY:...>
alias2, Sep 9, 2020,PrivateKeyEntry,
Certificate fingerprint (SHA1):<AA:BB:...>
)
but when I'm using this pfx in Postman I'm getting "Error: MULTIPLE_PRIVATE_KEYS_IN_PKCS12"!
When I'm using certificates individually then everything is working fine in Postman. I checked already that multiple PrivateKeyEntry can reside in a single .pfx file - Can a .pfx file contain more than one private key?.
Instead of maintaining separate pfx files to connect separate systems I want to keep all certificate entries in a single file (pfx) so that can be used for all the different systems.
Is it possible?
Thanks in advance!
You can convert pfx certificate into another format. Crt+key works for me.
You can use OpenSSL to convert certificate:
openssl pkcs12 -in certificate.pfx -clcerts -nokeys -out certificate.crt
openssl pkcs12 -in certificate.pfx -nocerts -out key-encrypted.key
I'm working on a box that's running CentOS (Linux), and I'm running into the following error when try to access a particular subdomain for work:
Traceback (most recent call last):
... # My code, relevant call is requests.get(url)
File "/usr/local/lib/python2.7/site-packages/requests/api.py", line 60, in get
return request('get', url, **kwargs)
File "/usr/local/lib/python2.7/site-packages/requests/api.py", line 49, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 457, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python2.7/site-packages/requests/sessions.py", line 569, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python2.7/site-packages/requests/adapters.py", line 420, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: [Errno 1] _ssl.c:504: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
According to https://www.digicert.com/help/, the subdomain "is not sending the required intermediate certificate" (and that's the only problem DigiCert found). However, my code handles this without problem when I run it from my Mac laptop, and so do both Chrome and Safari. I'm running Python 2.7.5 on both my laptop and the linux box. I was running requests 1.2.0 on the linux box and 2.2.1 on my laptop, but I upgraded both to 2.4.3 and they still don't have the same behavior.
Also possibly relevant - the same certificate is being used with some other subdomains where the intermediate certificate is being sent, and neither my laptop nor the linux box has any problems with those, so it shouldn't be that my laptop has a root CA that the linux box doesn't have.
Does anyone know why it isn't working from my linux box and how I can fix it?
I spent a day to understand and fix this issue completely, so I thought it will be nice to share my findings with everybody :-)! Here are my results:
It is a common flaw in SSL server configurations to provide an incomplete chain of certificates, often omitting intermediate certificates. For instance, a site I was working with did not include the common DigiCert "intermediate" certificate "DigiCert TLS RSA SHA256 2020 CA1" in the server's response.
Because this configuration flaw is common, most but not all modern browsers implement a technique called "AIA Fetching" to fix this on the fly (see e.g. https://www.thesslstore.com/blog/aia-fetching/).
Python's SSL support does not support AIA Fetching and depends on a complete chain of certificates from the server; otherwise it throws an exception, like so
SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1124)')))
There is an ongoing discussion about whether AIA Fetching should be added to Python, e.g. in this thread: https://bugs.python.org/issue18617#msg293894.
My impression is that this will remain an open issue for the foreseeable future.
Now, how can we fix that?
Install certifi, if you have not done so, or update it
pip install certifi
or
pip install certifi --upgrade
Many (but not all) Python modules can use the certificates from certifi, and certifi takes them from the Mozilla CA Certificate initiative (https://wiki.mozilla.org/CA). Basically, certifi creates a clean *.pem file from the Mozilla site and provides a lightweight Python interface for accessing that file.
Download the missing certificate as a file in PEM syntax, e.g. from https://www.digicert.com/kb/digicert-root-certificates.htm, or from a trusted browser.
Locate the certifi *.PEM certificate file with
import certifi
print(certifi.where())
Note: I recommend to first activate the virtual environment (e.g. conda activate <envname>) you want to use the certificate with. The file path will differ. If you apply this to your base environment, any potential flawed certificate will put the entire SSL mechanism for all your code at risk.
Example:
/Users/username/anaconda3/envs/environment_name/lib/python3.8/site-packages/certifi/cacert.pem
Take a simple text editor, open that file, and insert the missing certificate at the beginning right after the header, like so
##
## Bundle of CA Root Certificates
##
...
-----BEGIN CERTIFICATE-----
+I2tIJLYrVJmuzHZ9bjPvXj1hJeRPG/cUJ9WIQDgLGB
Afr5yjK7tI4nhyfFK3TUqNaX3sNk+crOU6J
---> This is the additional certificate.
+I2tIJLYrVJmuzHZ9bjPvXj1hJeRPG/cUJ9WIQDgLGB
Afr5yjK7tI4nhyfFK3TUqNaX3sNk+crOU6J
-----END CERTIFICATE-----
It is important to include the begin and end markers.
Save the file and you should be all set!.
You can test that it works with the following few lines:
# Python 3
import urllib.request import certifi import requests
URL = 'https://www.the_url_that_caused_the_trouble.org'
print('Trying urllib.request.urlopen().')
r = urllib.request.urlopen(URL)
print(f'urllib.request.urlopen\n================\n {r.read()[:80]}')
print('Trying requests.get().')
r = requests.get(URL)
print(f'requests.get()\n================\n {r.text[:80]}')
Note: The general SSL certificates, e.g. for openssl, might be located elsewhere, so you may have to try the same approach there:
/Users/username/anaconda3/envs/environment_name/ssl
Voila!
Notes:
When you update certifi or create a new virtual environment, the changes will likely be lost, but I think that is actually good design, because it does not perpetuate a temporary security tweak to your entire system.
Naturally, the process of downloading the certificate is a potential security risk - if that download is compromised, your entire SSL chain might be, too.
The maintenance of certifi lags behind the Mozilla releases of certificates. If you want to use the most current version of the Mozilla CA bundles with certifi, you can use my script from https://github.com/mfhepp/update_certifi_certificates.
I still don't understand why it's working one place but not another, but I did find a somewhat acceptable workaround that's much better than turning off certificate verification.
According to the requests library documentation, it will use certifi if it is installed on the system. So I installed certifi
sudo pip install certifi
and then modified the .pem file it uses. You can find the file location using certifi.where():
>>> import certifi
>>> certifi.where()
'/usr/local/lib/python2.7/site-packages/certifi/cacert.pem'
I added the intermediate key to that .pem file, and it works now. FYI, the .pem file expects certificates to show up like
-----BEGIN CERTIFICATE-----
<certificate here>
-----END CERTIFICATE-----
WARNING: This is not really a solution, only a workaround. Telling your system to trust a certificate can be dangerous from a security point of view. If you don't understand certificates then don't use this workaround unless your other option is to turn off certificate verification entirely.
Also, from the requests documentation:
For the sake of security we recommend upgrading certifi frequently!
I assume that when you upgrade certifi you'll have to redo any changes you made to the file. I haven't looked at it enough to see how to make a change that won't be overwritten when certifi gets updated.
If you are on *nix and your intermediate or self-signed certificate is installed in SSL (i.e. you can hit the URL successfully from CURL but not from Python), you can set the environment variable REQUESTS_CA_BUNDLE to where your ca-certificates are stored (ex. /etc/ssl/certs/ca-certificates.crt).
Credit here.
I got a problem when I try to deploy the WSO2 EMM server.
In the doc https://docs.wso2.org/display/EMM101/iOS+Server+Configurations, step 7.b, when I try to execute this command:
keytool -importkeystore -srckeystore ca.p12 -srcstoretype PKCS12 -destkeystore wso2mobilemdm.jks
I got this error message:
"keytool error: java.io.IOException: Invalid keystore format"
looks like the wso2mobilemdm.jks is corrupt? I copy the wso2mobilemdm.jks from the binary package
"wso2mobileserver-1.0.1\repository\resources\security\wso2mobilemdm.jks"
Anything wrong?
This problem happened with me also. Reason in my case was "Keystore" was created using different jdk i.e. oracle jdk, And I was trying to open it with keytool command available in IBM's jdk. Once I tried with oracle jdk it worked.
That is because you are entering a wrong password. Just delete that file and execute this command again. It will create a new wso2mobilemdm.jks. Enter your passwords there. Also import the ra.p12 to the same keystore file you just created. There is no harm doing this since wso2mobilemdm.jks only will contain ca and ra entries.
For my ColdFusion 8 server, I can see the cacerts file in the
following path: C:\ColdFusion8\runtime\jre\bin
However, the cacert file is not present on my ColdFusion 9 server at the same location.
I am trying to install a cert into the ColdFusion truststore by following the
following steps:
1) Run the command prompt as administrator on the ColdFusion server
2) Make a backup of the original cacerts file in case you run into issues
3) Change the directory to your truststore’s location (where cacerts file is located).
In our case: C:\ColdFusion8\runtime\jre\bin
4) Type this command (use current JVM and use current JVM’s keytool):
C:\ColdFusion8\runtime\jre\bin>keytool -import -v -alias exported -file C:\ColdF
usion8\runtime\jre\lib\security\exported.cer -keystore cacerts -storepass changeit
5) Type yes at the prompt to “Trust this certificate?”
6) Restart the ColdFusion service It will not read the updated cacerts file until you do this.
Is there something new for ColdFusion 9? I have successfully installed the certificate for ColdFusion 8 following the above steps? Please advise
The default truststore is the JRE's cacerts file. This file is typically located in the following places:
Server Configuration:
cf_root/runtime/jre/lib/security/cacerts
Multiserver/J2EE on JRun 4 Configuration:
jrun_root/jre/lib/security/cacerts
Sun JDK installation:
jdk_root/jre/lib/security/cacerts
You can verify the JRE that ColdFusion is using from the administrator under the 'System Information' page. Look for the Java Home line.