I have a use case where I am trying to connect to an HTTPS server. Initially I was thinking to use JRE cacert file for SSL handshaking and server certificate validation.
But now this seems not possible and I have to create my own user-defined truststore/keystore.
Can anybody let me know how to create a truststore/keystore to be used while communicating with an HTTPS server?
Once the truststore/keystore is created I should be able to install a self-signed server certificate and if needed remove it from the store programmatically using the class keystore.
Regards,
Mano
Related
Hello Everyone
Is it possible to upload SSL certificate in (local) IIS ?
if so , please provide me for the steps
if it is not possible, how can I make it runs in a global
sorry for the stupids questions but I am really newb in IIS
I would like to know more details about “upload SSL certificate in IIS”. In my opinion, IIS can create a self-signed certificate by using the Server certificate tool.
Also, it supports that importing a PFX file to the certificate store.
We can also import it to the local machine certificates store by clicking the certificate file to install it so that every user account in the machine can refer to the certificate when binding a certificate to a port.
Finally, a certificate is commonly used to bind to a port so that secure the communication. We could refer to this link.
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-configure-an-iis-hosted-wcf-service-with-ssl
Feel free to let me know if there is anything I can help with.
our company proxy brokes the SSL Connections and the proxy use our own CA.
So i have always tell the applications i use (RubyGems, Python Pip, Azure CLI ...) to use our company CA Certificate.
Does anyone know, how i can use our CA Certificate with a local Terraform installation?
Is the CA deployed to your OS's certificate store or can you import it? If so, Terraform (and probably other tools) should just be able to work with a proxy like this with no other configuration. If you need some further direction, tell us what operating system and how you typically access you have to the CA.
Edit:
#Kreikeneka have you have the certain the location CentOS expects to import into the store. There is a command you need to run that actually imports it update-ca-trust. Have you run this? If the cert is being used for SSL and you just need to trust it when going through your proxy, that is all you should need to do. You shouldn't need to tell your tools (Terraform, PIP, etc) to trust it for SSL with the proxy. If the cert is imported into your certificate store, it should be passively usable from any connection on from the machine from any process.
If you are using the cert for client authentication to the proxy then just trusting the cert by placing it in the certificate store probably won't work.
I'm not clear from your comments if you need the cert for SSL or for client authentication to the proxy. Check with your IT what it is really used for if you aren't sure and get back to us.
As of CentOS 6+, there is a tool for this. Per this guide,
certificates can be installed first by enabling the system shared CA
store:
update-ca-trust enable
Then placing the certificates to trust as CA's
in /etc/pki/ca-trust/source/anchors/ for high priority
(non-overridable), or /usr/share/pki/ca-trust-source/ (lower priority,
overridable), and finally updating the system store with:
update-ca-trust extract
Et voila, system tools will now trust those
certificates when making secure connections!
Source:
https://serverfault.com/questions/511812/how-does-one-install-a-custom-ca-certificate-on-centos
We have a website with SSL configured. 2 days back SSL certificate was expired so I purchased a new instead of renewing. I have configured the new one. Now some of users are still getting SSL certificate expired issue although the new one is configured.
I want to force the browser to recheck the new SSL certificate using some server side configuration since we can not go and update each user browser certificate manually. It have to be done using some server side configuration. We are using Nginx.
This is really critical to us.
Please help in this regard.
Thanks!
The certificate is validated by the client only when the server sends one. The server sends one with each full TLS handshake. The browser does not somehow cache an old certificate and ignore the one sent by the server when validating.
It is more likely that you've not fully rolled out the new certificate on the server side. For example if you have multiple servers make sure that all have the new certificate. If your server provides access for IPv4 and IPv6 make sure that in both cases the proper certificate is served. If you provide service on multiple ports make sure that they all use the new certificate.
It's also possible your affected users are behind a proxy that caches certificates. For example if they're behind a Smoothwall proxy that generates its own certificates after inspecting HTTPS traffic and caches them.
Either way, if you've updated the certificates on your server and restarted the necessary services, it's probably nothing you have control over and will most likely resolve itself in time.
Someone just asked me to create an SSL certificate for a server that hasn't been created yet.
In fact, it's going to be hosted, so I won't even have a linux account to ssh into it.
Normally I would create the CSR on the server, and then send it to a registrar like Thawte.
Does this request make sense ? Is it possible to create an SSL cert without having ssh access to a server ? Or is my boss not understanding the process?
For web server running over https protocol, the important component of SSL certificate is the subject's CN field. This field is matched by browser against the DNS record to verify the web server is indeed whoever it claimed to be
You can purchase a SSL certificate without physically provisioning the server. However as part of purchase procedure the CA will perform domain ownership verification (and more rigorous vetting if you purchase OV/EV certs)
It doesn't matter where (physically) the command to generate private key and issue CSR is executed as long as the final product is installed once the server is provisioned
Furthermore, repointing the DNS record to different server doesn't require new cert to be issued. The important thing is you decide on DNS entry name.
Yes, you can create the CSR (PKCS10) on a different server than the one you install the certificate on. Just make sure you get the whole pfx back, with both the private and public key. However, it will now work if you have a HSM, as the private key will be stored in the HSM, and not be transportable.
I have a thick client written in VB6 that connects to an Sql Server 2005 Database. I want to secure the connection by using SSL between the client and DB.
I've looked at these links for details on "how to" configure it.
http://msdn.microsoft.com/en-us/library/ms189067%28SQL.90%29.aspx
Question
If I want to buy an SSL certificate to use in this scenario, do I just buy the standard SSL certificate sold for websites? I would imagine so, but I want to make sure.
I guess SSL certificates are standard and can be utilized anywhere as long as the client and server know how to use that protocol.
But in case I do buy a standard SSL certificate, what do I mention as far as my website domain address etc? - Since I'm going to use it between thick VB6 client and SQL Server 2005, I wasn't clear how to go about this.
Is there any other (easier) way of securing the connection between a thick client and Sql Svr DB? My requirement is to only make the connection secure....it doesnt have to be SSL.
Thanks
Amit
You need to use a certificate trusted by the client. You can choose between using one of the trusted certificate authorities (VeriSign, Thawte, GlobalSign) or deploy a root of trust on your clients. The DB client validates the certificate the same way all SSL certificates are validated, by verifying the Subject against the name used by the client to connect.
Given that a normal DB deployment you know what your clients are, then it makes a lot of sense to pre-deploy the certificate used on the client and save yourself the cost of a true SSL system trusted authority signed cert.
If your DB clients are open ended and can add themselves at will, then it doesn't make sense to have them connect to the DB directly. Point is that there must be a deployment step (a Setup) that adds the new client to be trusted on the back end, and this step can also deploy your own root certificate as a new trusted root on the client, or, if the client is paranoid about adding an entire root, just the certificate used by the server as a trusted cert.