We have Application Server hosted a Web Site Portal in SharePoint 2007 and a SilverLight Application as subsite. We need to change the SSL Certificate of the server. What are the potential impacts on changing the SSL certificate?
If you sign the certificate using a known CA (say VeriSign, Thwate), there should be no impact. The procedure should be seamless.
Related
We have a number of internal apps which have website access - this is set up on Windows Server 2016 through IIS.
We create the SSL certificate for these apps through "Certify the Web". These are updated automatically. These SSL certificates are binded to the websites through IIS and seem to update automatically as required.
However when we navigate to these websites they state that the SSL certificates are invalid, with the old dated certificate which expired a while ago.
Anything you guys suggest for this?
I have a quick question on opting the SSL Certificate for the Web Application. In the Web Application, am using Kestrel as WebServer and application is not configured in IIS.
For Customers, I install the Application as a Service in Server Machine and its used by the employees only in intranet. Now the address of my application is http://machineName:port but I would like to have https://machineName:port.
Question 1) Is this possible for the Intranet sites?
Question 2) Will SSL be really needed in this case?
Qeustion 3) SSL works, only if I configure Web Application with IIS?
Yes it is possible. As long as the certificate is trusted by the clients. You can create a self signed certificate and have client machines add it to trusted root certificate authorities in windows. Or if the intranet is using a windows domain, you can have a Certificate Authority trusted by domain computers issue the certificate.
SSL is always better even in intranet and localhost scenarios. It ensures site identity, encrypts traffic, etc. Whether it is needed depends on the site. Some browser functionality such as using the camera/mic won't work unless the website is using SSL.
Kestrel allows using SSL. Checkout docs here.
I have created an asp.net web application and deployed it in IIS10. The design of the application is to require a client certificate for each user which will be provided by us. For testing purposes I created a self-signed certificate using the makecert.exe and followed the instructions at https://blog.jayway.com/2014/10/27/configure-iis-to-use-your-self-signed-certificates-with-your-application/. I added the certificate in the MMC Personal Certificates.
I also configured the iisClientCertificateMappingAuthentication in the IIS Configuration Editor using the one-to-one mapping approach. When I tested it on the browser, at first it asked for a digital certificate (which is correct), but when I clicked the certificate I added on the bindings it returns an error "Your client certificate is either not trusted or is invalid."
What should be the problem here since the installed client certificate is already added in the IIS one to one mapping configuration? Do I need additional configuration in the IIS?
What are the best practices for updating client-side SSL certificates without user interaction?
To be more specific:
I have a server with SSL private key/public x.509 certificate.
All clients will communicate with this server through SSL.
In order to establish SSL connection all clients need to import the server's public certificate to their trusted locations (truststore).
Getting the server's certificate at (client) install time is not a problem because the installer can contact the server (by SSL) and get the server's public key (or the company's Root Certificate). After that the installer can show the certificate to the user for visual validation and this is secure enough.
What will happen after the server certificate (or the company CA) expires?
Or what will happen if the server certificate is accidentally changed?
What are the best practices to (automatically) update all clients with the new server SSL certificate (CA)? Having in mind that after installation the clients are background processes and the is not visual user interaction possible.
Of course the easiest way is to manually update all clients by the infrastructure administrator.
I'm wondering if there are some known good practices to automatically update the client's certificates without user intervention?
Ideally, your server certificates should be issued and signed by a trusted root CA certificate with a long lifetime (10 to 20 years). Just the root CA certificate would be installed on the client end.
The server certificate itself, even if you update it every year, would not need to be propogated to clients since the root signed it and is trusted.
If you're using self-signed certificates, this is why they are generally frowned upon from a certificate management perspective. When they expire or change, you need everyone to update - otherwise you'll get browser security warnings.
Was wondering what the best practice for deploying a custom WCF - Security Token Service (STS) in a load balancing environment that uses signs and encrypts the token?
We're using Cirtix NetScaler to handle the load balancing and SSL termination (i.e. certificate is only installed on the NetScaler server). The STS has been specified to sign and encrypt the token via the SigningCertificateName and EncryptionCertificateName app settings. However the current web server configuration does not have a local certificate installed within it's certification store.
So my questions are:-
Do we need to worry about signing and encrypting the token if it's transferred over SSL?
Should we install the certificate on every web server or can we use the load balancer?
Can we use the same certificate on each web server or do we need to buy a certificate for each web server?
An STS which does not sign its tokens is not much use: without a signature, no relying party will be able to distinguish between a valid token issued by the STS and a token spoofed by someone with evil intent.
The certificate you install to support SSL is generally different to the STS's signing certificate. The latter identifies the Service, not the web server. So, by all means carry on installing the SSL certificate just on the load balancer. But you will need another certificate, representing the identity of the Service, installed (with its private key) on each machine which hosts the service, for use as the SigningCertificate. It should be the same certificate on each server (it's the same Service).
However, you typically don't need to buy such a certificate: you can issue your own - you just need to make sure each potential Relying Party is configured to recognise the certificate as a trusted STS, and also trusts the root issuer of the certificate (which will be either the certificate itself, if it is a self-signed certificate, or your root certificate, if you used a certificate server to issue it).