My current certificate for web service validity is no longer valid, It has expired. Is there any way to extend the existing certificate.? Or else I should only create new and add it to key store again. thanks
I know of no way to extend an expired certificate. If its your own self-signed certificate. I would generate a new certificate and add to keystore as you suggested.
Related
Can anyone help me that I am using load balancer in google cloud platform but here I am not able to properly install ssl. Only certificate chain and private key box is showing not public key box. Why it is happening ? Is I have missed something or glitch from google side ?
**public key => But where to upload this ??
certificate chain => available
private key => available**
Which one is certificate chain in these that google is asking ?
And when checking it is showing grade B due to incomplete chain
As I suspected in the comment section, the issue was with a self-managed certificate (Trust Chain).
When creating a Certificate in GCP you can use Google-Managed and Self-Managed certificates.
In this setup OP used GoDaddy Certificate and validated it on ssllabs. One of the issues was
This server's certificate chain is incomplete. Grade capped to B.
More details can be found in this article - How Certificate Chains Work
A certificate chain is an ordered list of certificates, containing an SSL/TLS Certificate and Certificate Authority (CA) Certificates, that enable the receiver to verify that the sender and all CA's are trustworthy.
In Using self-managed SSL certificates - Step 2: Create a self-managed SSL certificate resource guide you can find information that chain certificate needs to be verified by the user:
Paste in your certificate or click Upload to navigate to your certificate file.
You can choose to include the CA certificate chain in the same file as the certificate. Google Cloud does not
validate the certificate chain for you – validation is your responsibility.
There is also information about the trust chain when you are creating a Certificate in GCP via UI, that your trust chain must be correct.
The certificate must be in PEM format and include correct certificate trust chain. The certificate chain must be no greater than 5 certs long.
Solution
Solution to this issue was to merge the certificate chain with OP's certificate.
Useful links
Creating a .pem File for SSL Certificate Installations, especially part Creating a .pem with the Private Key and Entire Trust Chain
How to combine various certificates into single .pem
You don't need to upload the Public Key to the LoadBalancer. Only the certificate and Private Key are needed.
The Public key portion is embedded into the Certificate
Just add main security certificate at the top of certificate chain mostly contains 3 to 4 certificates and add this final certificate in certificate field while creating a certificate. then all things will be corrcted. Thank you enjoy.
I have websites that link directly to images stores on S3 using HTTPS.
For example:
<img src="https://s3.amazonaws.com/MyBucket/FolderInBucket/ImageFileName.png" />
I wanted to know if I need to change anything so my images on my website will still be accessible after the migration.
Source information link.
You won't have to do anything on your end, the certificate swap is handled by AWS. Whether this has an impact on your application depends on your clients, because this change relates to how they do the certificate verification.
The process is roughly like this:
The client makes a request to S3, asking for encrypted communication
S3 sends back a certificate, that contains the public key for the initial key exchange using asymmetric encryption.
The client verifies the digital signature of the certificate, that means:
The certificate is cryptographically signed by a certificate authority (there are intermediate certificate authorities that form a chain of trust, but we're going to ignore these for simplicity.)
This signature means the certificate authority guarantees this certificate to be valid
The signature is trusted, if the certificate authority is trusted. Each client has a list of trusted root certificates in a local trust store, which the client trusts to guarantee the authenticity of certificates
If the new CA is in the local trust store everything is fine, if it isn't there will be an error
Afterwards the client will check, if the certificate in question has been revoked. If yes, the connection is terminated, if not it trusts the certificate and the included public key
The client generates a session key and encrypts it with the public key from the certificate.
The encrypted session key is sent to the server and the server can decrypt it using its private key
Now both partners have the session key and can exchange symmetrically encrypted messages using that session key.
So the main question is: Do your clients have the new CA in their trust store?
The answer is: most likely yes
You can have your clients test this by accessing the URL in the post you linked to, which already uses the new certificate:
https://s3-ats-migration-test.s3.eu-west-3.amazonaws.com/test.jpg
If they see this picture, everything is fine:
You can also do this in the background on your website and check if HTTP 200 is returned when requesting the URL. If that's not the case, inform the client there may be problems in the future.
Using WSO2 APIM 2.6.0 seems the primary keystore certificate is used for multiple purposes
service (nio-https) SSL - that can be easily changed
signing a JWT token to the API Gateway backend service
thrift SSL endpoint for the Traffic Manager (port 9711)
The issue I have is that in a distributed setup a separate gateway should reach the TM endpoint and the hostname needs to be trusted. So - in theory I can create a self-signed certificate with a new hostname, however a new keypair/certificate will break existing backend validating the JWT token.
In theory I may just create a different self-signed certificate with the same public key, it may be more complex to manage in long run (I don't want to promote this practice).
Question: Is there a way to configure either the JWT signing certificate or the thrift SSL certificate separately? Or disable hostname validation for the throttling service (port 9711)?
(I'm not sure we want to allow disabling the hostname validation globally)
Since you have a distributed setup, this can be achieved easily.
You need to change the certificate in the gateways so that they use that keystore for the TM connection.
Keep the KM keystore as it is so that JWT is signed using the same old keystore.
I generated an SSL Certificate for my google instance cdn for the past 12 months all has been working fine, until now when after renewing the certificate with certbot when I tried to add the new certificate it fails
on the CDN console.
Interestingly the certificate works fine on https://dev.owinomart.com
but google complains that "The SSL certificate and key do not match".
When adding on the Instance, I even re-created a solo certificate for https://cdn.owinomart.com.
Creating SSL certificate "certificate-september-25-2018" failed.
Error: The SSL certificate and key do not match.
The certificate was generated for
https://dev.owinomart.com and
https://cdn.owinomart.com
It worked fine for dev but failed on cdn(which is a google CDN instance)
What could be the problem?
From your comment, it sounds like you are adding a certificate to an existing domain.
a) Please confirm that you are adding a certificate to https://cdn.owinomart.com and not deleting the old certificate resources.
From our findings, such a thing might happen when multiple keys exist, and so the Certificate Signing Request (CSR) is unable to find the correct key.
b) Please also make sure you have created a separate folder and generated a new private key along with the certificate.
I would like to point to "Creating SSL certificate resource" section of public documentation on Creating and Using SSL Certificates and would like to know which of the two scenarios you are following - that is, creating a new key with a new certificate or Creating CSR from existing certificate files?
Lastly, I am also sharing you a link on ’How do I verify that a private key matches a certificate?’ If it matches, you could manually copy the private key to the Google CDN instance.
If the modulus of the certificate and the modulus of the private key do not match, then you're not using the right private key. You can either create a brand new key and CSR and send contact support or do a search for all private keys on the system and compare their modulus.
I have a web service that clients will have and I want the data that's sent to the server encrypted. To test this I used a self signed SSL certificate. I know that when you use a self signed cert and when you navigate to whatever address is using it that the web browser will warn you that it's unsafe etc.
I am wondering if I'm I going to run into any problems if I used this certificate instead of a verified one when the web service goes live?
Also I don't have a domain name for the server, so I am just going to use the IP address given by my ISP, is this ok to do so with the certificate, because everywhere I read about them people are talking about using them with domain names?
An SSL certificate is usually issued to a domain and is signed by an issuing authority. When a browser connects to a server the server presents its certificate to the client. The client then verifies the certificate by checking if the domain that it is accessing is the same one as mentioned in the certificate. Also, it verifies its trust chain. This means that the issuer's certificate should also be valid. If the issuer is not the root signing authority then the issuer's issuer's certificate is verified. And, ultimately the root signing authority should be trusted which means the root signing authority should be in your truststore. All major signing authorities like Verisign, Thawte etc are by default in the JDK trustore hence if you have a certificate signed by them then you do not have issues in the verification of your trust chain. If your certificate is signed by an authority that is not trusted then you need to import the issuer's certificate in your trust chain manually.
Now, when using a self signed certificate, the entity to whom the certificate is issued is itself is the root signing authority. And hence the certificate should be imported into your truststore manually. You need to do this to get your SSL handshake through. But this alone does not solve your problem. Since, you are not using any domain name, your IP is likely to be changed every time you restart your server if you are obtaining your server IP automatically through a DHCP server. If this is the case then even a trusted self signed certificate won't work once the IP changes. Because, the certificate is issued to an IP and once the IP changes the certificate would become invalid. To get around this you need to get a static IP address for your server from your network admin. Then generate a self signed certificate for your static IP. Then ask your clients to add your server certificate in their trust store.
This would be a bit tedious for your clients. But, if you have a fixed number of clients and the client machines are under your control then you could add the server certificate to the client trust store yourself. But, if your server is open to all or have a huge number of client then I would suggest to get a certificate signed by a well known and trusted certification authority. Again, you would still need to have a static IP irrespective of who signs your certificate unless your server gets a domain name.
The issue with self-signed certificates is the same in any scenario, browser or non-browser: it assures absolutely nothing by itself. The purpose of SSL is two-fold: encryption and authentication. Typically both aspects are being used/required by SSL clients for a connection to be really regarded as secure.
For authentication ("who am I talking to?"), certificates are used. To authenticate your peer with a certificate, you will either have to have a copy of that certificate to compare to, or you will need to have a copy of the certificate of a signer of that certificate to compare the signature to. If you have neither, the certificate doesn't assure anything.
Meaning: self-signed certificates are fine if the client has a copy of that certificate and can trust the source of where they got the certificate from. If you have a very narrow use case where every client that's going to connect to your web service will have had prior contact with you (e.g. via email) and you are able to give a copy of the certificate to them for them to install into their local trust store, then they are able to establish a secure and authenticated connection to you regardless.
This is not workable for a typical website with arbitrary, random visitors; that's what signed certificates are for, where an already trusted entity can vouch for a heretofore unknown 3rd entity. It may be workable in a vendor-customer scenario though.
Having said that, certificates are dirt-cheap to free nowadays and lend more credibility and professionalism to your service.
And yes, certificates can be issued for IP addresses.