I am trying to set an HTTP load balancer with SSL.
I have two files - certificate.pem and unencryptedkey.pem.
But the UI of google asks for three fields:
Public key certificate,
Certificate chain,
Private key
What goes where and where do I get the third one?
I managed to use only 2 but the browser asks for permission and that is wrong.
When you buy the SSL certificate you should get some more files. In my case, I got a .ca file (certificate chain), a .crt file (the certificate), a .csr file (the request), and a .key file (your private key)
You need
public key => the crt file
certificate chain => your ca file(s concatenated)
private key => your .key
My guess is that you have created the certificates, i.e. you haven't purchased them from some certificate authority. With self-signed certificates browser warns you, since certificate validity can't be verified from a certificate authority.
If this is the case, you should do some learning regarding certificates and how they work.
Related
A wildcard certificate from Godaddy was recently purchased by my organization. While walking through the steps on the Godaddy's site to setup the cert, I typed in the domain name instead of uploading a CSR. Fast forward, this will be for Windows servers and I downloaded the certificate bundle. I see one PEM file and two CRT files. In short, the PEM file is really a Certificate and not the private key. Since I did not upload a CSR and let Godaddy do this, how do I get the private key?
I need to create a PEM file of a SSL (CA) certificate. Chrome does provide an option to view the certficate and export it as Base64 encoded X.509 (.CER)* file. In addition, the file extension can be changed to .PEM. Does the certificate only contain public information and can it safely be shared with other people (let's say colleagues)?
E.g. Stackoverflow contains a Root CA certificate. If I create the PEM file and share it with somebody, does it even matter or is there any security risk?
Background info: I need to export the SSL certificate (as .PEM) from an API endpoint in order to add it as trusted CA certificate in Postman.
i think i have an error on my understanding on the SSL handshake, but do i?
My application cant verify itself on the api. After some digging with wireshark i noticed that theres no "certificate verify" step and my private key certificate is not signed with one of the trusted authorities so my first thought was that.
The catch is: If i add the same certificate to my browser(firefox) and call the API i get a popup for the certificate selection and it actually works.
Isnt it supposed to only accept certificates that are listed under the Distinguished Names? Or is this only required for the public key and the private not necessarily?
What does firefox actually do in background when the popup comes, create a custom certificate chain?
Setup is as followed:
API is under https:somerandomurl
API-Server integrated a certificate of ours for auth (for all i know)
(this cert is actually a cert for https:someotherurl)
Client has truststore with cert for somerandomurl
Client has keystore with PKCS#12 cert
My guess is that my application has wrong/no certificate chain because as far as i know the PKCS#12 cert contains a pub and a private key BUT the pub is not for "somerandomurl" but "someotherurl". But thats just a guess, maybe its just the trusted auths
We have a XMPP server using SSL certificates (for both the server and the clients).
We use a self-signed CA to sign those certificates. Now we want to stop using that self-signed CA, but we have no idea how to replace those certificates to ones signed by an authority like Digicert or GlobalSign, since we don't know what to buy to do the same we usually do (we usually just create a public key, then a request and we sign it using the self-signed CA, and then voila, we have a certificate ready for the client to use)
Any ideas?
Thanks a lot.
we usually just create a public key, then a request and we sign it using the self-signed CA, and then voila, we have a certificate ready for the client to use)
The process is the same as for a Certificate Authority, with the difference you probably have to pay for the certificate
generate a key pair,private and public. (Not only the public)
Generate a Certificate Signing Request including the public key, some data about the certificate as Common Name, and sign it with the private key.
Send the CSR to the Certificate Authority
The CA validates the CSR, builds the certificate and signs it with its private key
Finally the CA sends you the certificate
We have an Azure web role deployed that uses HTTPS. We upload a certificate to azure and shortly after the portal refreshes and two more certificate appear. This is not a wild cart certificate and maybe this is standard behavior, but I haven't seen it before.
The original certificate is named something like:
subdomain.domain.com
The three certificates that appear are named like so:
VeriSign Class 3 Public Primary Certification Authority - G5
Class 3 Public Primary Certification Authority
VeriSign Class 3 International Server CA - G3
Are the 3 certificates I mentioned normally generated or is this an issue I should be looking into?
We have a similar deployment that has an ssl, but does not generate these extra certificates. This is what triggered our concern and has me asking why ...?
When you enabled HTTPS endpoint in any web application and bind SSL certificate to it, the certificate bind to HTTPS endpoint is could be a single certificate or it could be a chain and
it is depend on several factors as below:
When the certificate is created as self signed ROOT then it will have only one certificate in the chain. This certificate can not be validated to have SSL tunnel because there is no other part to verify it and that why it is called self signed root
When you buy certificate from a reputed CA (Certificate Authority) in almost all cases you will get 3 (or more) certificates:
2.1. Root Certificate : This certificate is helps to create a SSL tunnel between two machines using PKI security Infrastructure.
2.2. Intermediate Certificate -> This is to create a chain with multiple certs as if needed
2.3. Domain Certificate -> This is for your *.domainname.com or domainname.com
Here is an example of chained SSL certificate at https://mail.google.com
And all of these certificate are chained into one single PFX (if private key embedded into certs) or CER (without any Private Key) so when you deploy only ONE PFX cert, you see the chain is open and all certificates are listed.
If you browser your url and open the certificate view through browser, you will see exactly same chain as you could see in your portal and you can also verify the certificate thumbprint as well to match.