I have a problem with updating SGD certificate on my local machine.
I am using a self-signed certificate, and can't get the certificate to change the valid from field (ends in 2022) although the new certificate in the .pem file is valid till 2024.
Certificate Information
I want to put a new cert here for SGD.
I have tried everything on the tarantella/sgd website and still no change.
Related
I have a VPS with Apache2.
I have installed SSL before in my websites, but always form freeSSL or ZeroSSL, they give me 3 files:
Private.key
ca_bundle.crt
certificate.crt
I replace them for the old ones and all is peachy (I configured it once and just replace the files on reactivation).
Now I have issued a year long SSL service from Comodo SSL, and they send me a mail with this information:
"Thank you for placing your order. We are pleased to announce that your PositiveSSL Certificate for * has been issued.
Attached to this email you should find a .zip file containing:
Root CA Certificate - AAACertificateServices.crt
Intermediate CA Certificate - USERTrustRSAAAACA.crt
Intermediate CA Certificate - SectigoRSADomainValidationSecureServerCA.crt
Your PositiveSSL Certificate - ***.crt
You can also find your PositiveSSL Certificate for ** in text format at the bottom of this email."
And I really have no Idea what to do... I tried Google but can't find any guide, they talk about CSR or other things and I just want to install this and forget about it for a year like I did before for 90 days...
Please help me, I need to have SSL running for my Magento 2 installation to work.
To use a certificate you need the certificate file itself (.crt) AND the key file (.key) ( Extensions may vary but, as you know, on linux it doesn't matter): if you're missing one of these, you're pretty much screwed.
To get a certificate, the following steps are necessary:
a key file needs to be generated
from the key file a CSR is generated
the CSR is signed by a CA (for you it's Comodo) and the result is the certificate file
The key file and the csr can be generate by you (who are requesting the new certificate) or (in this case) by Comodo during the procedure you followed. According to what you wrote, probably, during the procedure you've been asked to provide a key or let them generate one and you picked the 2nd option.
I've never used Comodo so I don't know how their interface works but IMHO you have 2 options: login with your account and look for an area where you can download the certificate and check for the possibility to download the key too OR contact them and ask for support to download the key file.
There is no way to use the certificate file without a key file.
I generated the certificate using an option of my webhosting service (Hostinger) to buy a comodo SSL certificate, as I said the email of Comodo didn't give me the key file BUT, after some hours the comodo ssl service started showing on my webhosting control center and going through some menus I reached a button called "download SSL", that downloaded a ZIP with the same files PLUS the key file. This was very random and nowhere stated, and I found it by coincidence but is solved. Thanks. The other option was to reach Comodo or Hostinger for help.
I ran into issue with expired certificates on k8s cluster. I am running version 1.6.1 for over a year now, meaning that my certificates expired and I have to renew them.
In newer versions this is already done automatically, but I currently can not upgrade my cluster to higher version, so I have to create certificates manually.
I came across following link, where it is described step-by-step, but I am actually already stuck on creating openssl.cnf file, as I am missing parameters. At the same time, this option is using .pem key, while on cluster currently .crt and .key pairs are used.
Any suggestion how to move forward with this? I have also tried running kubeadm alpha phase certs selfsign command, which created new certificates, yet I am still running into issue that api-server is refusing TSL handshake.
http: TLS handshake error from IP:port: remote error: tls: bad certificate
Thank you and best regards,
Bostjan
There is a detailed guide on how to generate certificates.
While you are following that guide look out for a few gotchas:
Make sure your CA certificate is valid for the period you are trying to extend the other certificates to. The validity of any certificates signed by the CA certificate are also limited by the expiration date of the CA certificate.
If the validity period of the CA certificate itself is too short you are in a pickle. Replacing that certificate will require modifying all kubeconfigs (operators, cluster components).
For the same reason as above, make very sure you don't overwrite the CA key/certificate accidentaly.
When replacing the certificate for the apiserver you will need to restart the apiserver. The apiserver does not reread the certificate automatically.
I'm trying to fix an issue related to an expired ca certificate.
I replaced a the certificate located at /etc/puppetlabs/puppet/ssl/ca/ca_crt.pem (with these instructions).
Then restarted puppet-server, but agents still see an expired certificate.
I noticed there is also a value localcacert which points to a slightly different path etc/puppetlabs/puppet/ssl/certs/ca.pem.
I see this little snippet on Puppet documentation:
Where each client stores the CA certificate.
Default: $certdir/ca.pem
I'm confused by this. The description makes it sound like a folder where clients store certificates, yet the value is a single pem file.
Can anyone clarify the difference between these two ca pem files?
If I update one can I just overwrite the other with my new pem?
Can anyone clarify the difference between these two ca pem files?
The cacert setting is relevant only to the master. It specifies the location of the certificate with which the master's hosted CA will sign communications.
The localcacert setting specifies the location of the client's copy of the CA certificate (containing the public key, not the private one). This is what machines will use to verify certificates signed by the CA.
In both cases, you should not read too much into the word "location". These settings designate certificate files, not directories.
I updated the SSL cert on a customer server. The cert was about to expire.
The customer sent me the new cert in PEM format. I just replaced it on Apache and restarted it. The new expiration date is correct, but I got a little validation error:
Unable to get the local issuer of the certificate. The issuer of a locally looked up certificate could not be found. Normally this indicates that not all intermediate certificates are installed on the server.
The cert uses an intermediate cert. Maybe I need to update the intermediate cert too ? Using the old cert, this validation error don't occur.
All seems to be working perfect. Browsers don't show any error.
You need to update the intermediate cert too, if it is different, as it seems to be. You might also want to check that the CA (Certificating Authority) cert has not changed, or if it has, add the new one.
I am trying to prepare for the switch in the SSL certificate vendors.
For the the SSL validation, Our Tomcat web application uses a JKS file created from a DigiCert certificate ( *.cer files). Our company is now switching to VeriSign next week. Since they have already provided the new *.cer files, can I simply add the new cert ( using keytool) to the existing JKS so that it works for both certificates. I am trying to avoid any downtime during the switch and prepare the server beforehand?
Any helps will be much appreciated.
You must install the certificate onto the same keystore you created the CSR from as the private key resides there. Otherwise it will not work. Please reference the article below on instructions on how to import into a tomcat server:
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR234&actp=search&viewlocale=en_US&searchid=1369174910074