I have a Linux VPS with Plesk control panel. Today, I have added one domain name [demovpstest.com] on my Linux VPS through the Plesk panel. When I am going to enable Let's Encrypt SSL Certificate for my website, I am receiving the following error.
Error: Could not issue a Let's Encrypt SSL/TLS certificate for demovpstest.com.
Details
Invalid response from https://acme-v02.api.letsencrypt.org/acme/order/68205530/1263660043
Details:
Type: urn:ietf:params:acme:error:malformed
Status: 404
Detail: No order for ID 1263660043
I've tried 2 - 3 times, but it failed. Please help me to solve this error.
This is a BUG than will be solved by Plesk, meanwhile this worked for me:
1-Connect to the Plesk server via SSH
2-Search for the JSON file which contains the Let's Encrypt order in the /usr/local/psa/var/modules/letsencrypt/orders folder:
egrep -Ril example.com /usr/local/psa/var/modules/letsencrypt/orders
/usr/local/psa/var/modules/letsencrypt/orders/c92788fed3b07d20e4ad823731285d30f0c88dcb.json
Note: replace the example.com with the name of the affected domain.
3-Remove the JSON file retrieved with the previous command:
rm /usr/local/psa/var/modules/letsencrypt/orders/c92788fed3b07d20e4ad823731285d30f0c88dcb.json
4-Reissue the Let's Encrypt certificate
Related
So I'm still in the process of updating a Drupal 7 site to 8 using drush and ddev.
After running the import, I get an error with upgrade_d7_file.
I've tried to install a certificate using this article:
https://www.ddev.com/ddev-local/ddev-local-trusted-https-certificates/
However still get the error, any ideas?
ddev exec drush migrate-import --all
ddev exec drush mmsg upgrade_d7_file
cURL error 60: SSL: no alternative certificate subject name matches target host name
'drupal7migration2.ddev.site'
(see https://curl.haxx.se/libcurl/c/libcurl-errors.html)
(https://drupal7migration2.ddev.site//sites/default/files/Virtual%20Challenges%20%28Results%20and%2
0PBs%29%2020200709.xlsx)
When you want one DDEV-Local project to talk to another using https, curl on the client side has to trust the server side that you're talking to. There are two ways to do this:
(built-in, no changes needed): Use ddev-<projectname>-web (the container name) as the target hostname in the URL. For example in your case, use curl https://ddev-drupal7migration2-web. This hostname is already trusted among various ddev projects.
(requires docker-compose.*.yaml): If you want to use the real full FQDN of the target project (https://drupal7migration2.ddev.site in your case) then you'll need to add that as an external_link in the client project's .ddev. So add a file named .ddev/docker-compose.external_links.yaml in the client side (migration1?) project, with these contents:
version: '3.6'
services:
web:
external_links:
- "ddev-router:drupal7migration2.ddev.site"
That will tell Docker to route requests to "drupal7migration2.ddev.site" to the ddev-router, and your container and curl trust it (it has that name in its cert list).
I try to do ssl connection for my server in c.
i have take this code : https://wiki.openssl.org/index.php/Simple_TLS_Server and I have generated certificate with certbot:
sudo certbot certonly --standalone
I have copy cert.pem and privkey.pem present in /etc/letsencrypt/live/MY_DOMAIN/ on my program directory.
but when I try to connect with curl, I get this error:
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
and my server print :
1996193792:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:../ssl/record/rec_layer_s3.c:1407:SSL alert number 48
thank you for your help !
That oversimple server does not handle a chain cert (or certs), also called intermediate, which every real CA this century requires, including LE. It is suitable only for test certs you generate yourself, or some limited environments like the intranet of a company that runs its own private CA.
Replace SSL_CTX_use_certificate_file on the cert.pem file with SSL_CTX_use_certificate_chain_file on the fullchain.pem file.
Also, SSLv23* methods have (finally!) been replaced by TLS* methods as of 1.1.0 in 2016, although the obsolete names remain as synonyms for now.
A pop-up window shows a warning message about a self signed certificate at every start of Outlook on a PC and on Samsung mail at the initial configuration.
Warning about the SSL certificate in Outlook 2016
Where is this certificate stored (Kolab 16 running on Ubuntu 18.04)? And how can I create new one?
This certificate is delivered by the Avast antivirus installed on a workstation. This certificate is stored in the workstation, not on the Kolab server.
To change the certificate associated to the warning about the SSL certificate in Outlook, you have to modify /etc/guam/sys.config and restart guam on the Kolab server :
1) At the line 29/79 of the file, you change the file path and the name of the certificate assiciated to the desired file.
2) At the line 46/79 of the file, you change the file path and the name of the certificate assiciated to the desired file.
3) And for a plus, you can modify the port 9993 at the line 10/79 for the port number 993 witch will correct a bug in the default file.
4) Restart the guam service by typing : service guam restart
The original certificate file /etc/ssl/kolab.installation.lan/cyrus-imapd.pem concactenates a certificate and a private key. So you can do the same with a command like :
cat fullchain.pem privkey.pem > crtprivkey.pem
I have set up a SQL Server database server on my Ubuntu 16 machine. To make it secure over a host network I am working on adding an SSL encryption certificate on it.
I tried following the steps as mentioned on this link ssl-encryption-mssql
But after restarting the service of SQL Server, it breaks giving the below exit code status
code=exited, status=1/FAILURE
I even tried to check the logs using journalctl -u mssql-server.service -b but it is not helpful at all. For the referrence, I am adding the screenshot of journalctl command below:
My /var/opt/mssql/mssql.conf looks something like this after following the steps from official doc.
[sqlagent]
enabled = false
[EULA]
accepteula = Y
[network]
tlscert = /etc/ssl/certs/cert.pem
tlskey = /etc/ssl/private/privkey.pem
tlsprotocols = 1.2
forceencryption = 1
EDIT-1: I further checked out the logs from /var/log/syslog, it stated the following log-
Error: 49940, Severity: 16, State: 1.Unable to open one or more of the user-specified certificate file(s). Verify that the certificate file(s) exist with read permissions for the user and group running SQL Server and found this question which seems similar, I tried the approach as told by Charles but it doesn't seem to work. Even I am using the Let's Encrypt Certificates.
EDIT-2: It is not a licensed version, could this be the reason?
How to resolve this error?
I just faced the same problem even though I followed the same steps as mentioned in the microsoft documentation. The actual problem seems to be with the permissions on the folder paths where the certificate files are located.
You can verify whether mssql user is able to connect or not using the openssl commands.
This command will do a basic verification on whether the certificates are valid or not.
sudo su - mssql -c "openssl verify -verbose -CAfile /etc/ssl/certs/mssql_ca.pem /etc/ssl/certs/cert.pem"
If you wanted to see if the combination of certificates are actually working or not (with key), you can start a openssl server service and then connect to it with another openssl client connection.
sudo su - mssql -c "openssl s_server -accept 8443 -cert /etc/ssl/certs/cert.pem -key /etc/ssl/private/privkeyrsa.pem -CAfile /etc/ssl/certs/mssql_ca.pem"
openssl s_client -connect localhost:8443
Another small correction from the documentation (I am using CA provided certificate), had to convert the key file format (might not require for you).
openssl rsa -in /etc/ssl/private/key.pem -out /etc/ssl/private/privkeyrsa.pem
When I used openssl APIs to validate server certificate (self signed), I got following error :
error 19 at 1 depth lookup:self signed certificate in certificate
chain
As per openssl documentation, this error (19) is
"X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN: self signed certificate in
certificate chain - the certificate chain could be built up using the
untrusted certificates but the root could not be found locally."
Why this error occurs ? Any problems with my server certificate ?
You have a certificate which is self-signed, so it's non-trusted by default, that's why OpenSSL complains. This warning is actually a good thing, because this scenario might also rise due to a man-in-the-middle attack.
To solve this, you'll need to install it as a trusted server. If it's signed by a non-trusted CA, you'll have to install that CA's certificate as well.
Have a look at this link about installing self-signed certificates.
Here is one-liner to verify certificate to be signed by specific CA:
openssl verify -verbose -x509_strict -CAfile ca.pem certificate.pem
This doesn't require to install CA anywhere.
See How does an SSL certificate chain bundle work? for details and correct certificate chain handling.
If you're running Charles and trying to build a docker container then you'll most likely get this error.
Make sure to disable Charles (macos) proxy under proxy -> macOS proxy
Charles is an
HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet.
So anything similar may cause the same issue.
The solution for the error is to add this line at the top of the code:
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
if you are testing your end points using Postman, just go to settings and disable "Enable SSL certificate verification"