We've an ASP.NET MVC4 app where there is a part which should be secured through client certificates.
When anyone wants to connect to this part of the app, browsers should ask them for a client certificate, once they select it, our server will get it, check it's validity and show the content.
Ok, I'm getting trouble with the select certificate part. Before setting it just to one folder on views content, I'm trying to configure this on the global app.
I've set SSL to be required, and also set require client certificates on SSL Configuration on apps configuration on IIS.
I've enabled the iisClientCertificateMappingAuthentication (although I've set no mapping yet)
When I try to access the app both, Firefox and Chrome, return a 403 forbidden error, stating that I have no access to the app with the credentials provided.
I've a client certificate installed on my local machine and the CA who created this certificate as a trusted root certificate on server local machine.
I'm not being prompted for certificate.
If I uncheck the "require" from client certificates on SSL Settings, I can access the app through https.
This is the first time I work with client certificates, so it's being a bit confusing and maybe I'm not giving enough info. Feel fre to ask for further info on the comments.
EDIT: I've exported the client certificate, copied it to the server and checked it there. The certificate shows as valid and every element in the certification chain seems to be recognized in the server.
I've checked IIS logs also, and the error I'm getting is 403.7, so the certificate is not being issued to the server or it's invalid.
Now... I've checked that the certificate is valid on the server, it's correctly installed on the client but it's not getting to the server or is not beign validated there... what am I missing here?
Ok, finally I've found the problem, it's related to the buffer size reserved for the list of trusted certification authorities.
Check this kb article:
https://support.microsoft.com/en-us/kb/933430
TL DR; To solve the problem just add a new entry in the registry at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
named SendTrustedIssuerList as a DWORD value with value 0.
This way, the server won't send the trusted certification authorities list, so browsers will display the complete list of certificates to the user.
Related
I have a secured website using a Network Solutions SSL cert. The website can be accessed from computers in environments in my company which have access to the Internet. (IIS redirects http calls to https). I have a browser in a locked down environment trying to access the same website using https. The locked down environment doesn't have access to the Internet but ports 80 and 443 are open to the website's server and I verified responses from telneting to ports 80 & 443. (not related to the error anyways). The IIS server has access to the Internet.
The response in IE is shown below.
Is the IE problem in that it doesn't have Internet access and so it can't connect to Network Solutions (NS) for verification or is it because of maybe missing root cert for NS? NS is a known authority so this is unlikely.
(I am troubleshooting WebAPI calls using https in case someone decides this is not a programming question. I have to make IE work correctly on the same machine before I look at the webapi stuff)
TL;TR: usually no internet access is needed to check the certificate on internal sites, but there are some edge cases.
There is no internet needed to access an internal site which has a certificate signed by an internal CA. There is also no internet access needed in most cases if the internal site has a certificate signed by a common public (i.e. external CA). There might be a slowdown in this case since it might try to check online for revocation information but in most cases it will just continue if it cannot reach the server for revocation checks. It might fail if the certificate is an EV certificate or if the browser is configured to do more strict revocation checks than usual.
But in your case it shows that the certificate was issued by an unknown CA. This means either the root CA for this certificate is not known at all on your system or the server failed to send the intermediate certificates required to build the trust path to the root CA. In the last case some browsers are able to work around such broken configuration by downloading the missing intermediate certificates from the internet - which of course requires internet access then. In the first case (missing root CA) an update of the root CA store could help which Microsoft browsers might do in the background if they have internet access.
I am trying to use SSL with my webapi published using IIS.
I've enabled SSL in webapi project by setting SSL ENABLED to TRUE.
On the local pc I've created a self signed certificate, which gets issued to MyPcNameHere/MyCompanyDomainHere. (not sure if that matters)
now if I browse to webpage in chrome/mozilla I get a warning... your connection is not secure. Mozilla's error is THE CERTIFICATE IS NOT TRUSTED BECAUSE IT IS SELF SIGNED.
What are my options here for handling this? (when I get this warning is the connection truly not secure? Or is it purely a warning that the certificate is self signed?)
I don't mind getting a third party certificate, but when I tried it wanted me to verify I own domain. This myPc/myDomain is inside a company firewall so I don't see how I could obtain a certificate.
any suggestions?
You get that error (warning actually) because you're using a self signed certificate, which your browser doesn't recognize.
Your options are:
obtain a certificate issued by a trusted provider (the root certificate of the issuer will be present in the trusted root certificates store of your browser/system
make the browser trust your self signed certificate (here's a guide for Chrome, I didn't find any for Mozilla - you have to just add a permanent exception)
Now, if you're using this only for a test, you can get the browser to trust your self signed certificate.
If you're in a company network, and you have the resources, you might consider setting up a local CA, which you then may use to issue certificates for testing machines on the Intranet, or for you dev environment. You will of course deploy the root certificate on all machines' trusted certificate store.
If you're going live with this (production machine accessible over the Internet), you have to really consider a provider.
I am writing to check if anyone has had a similar issue with Jasig CAS.
We are basic facing infinite redirects in the browser (In firefox: "Firefox has detected that the server is redirecting the request for this address in a way that will never complete.") after being able to log in CAS. It seems the client side does not get properly the authentication details ?
Since we have not done any code change, I think this is because a certificate change we did last night. We had a new ssl certificate from Verisign which we are using in all our servers., matching the server against our root domain.
Verisign certificate seem correct, and also intermediate ones...
Don't know if the old certificate could be cached somewhere in CAS or what could be the problem as to why the client and cas keep redirecting themselves, all only after we uploaded the new certificate into the Load Balancer (as the old one was expired).
Any ideas?
Disclaimer: I'm the Chairman of CAS and founder of CAS in the cloud (https://www.casinthecloud.com).
My guess would be that the new certificate, even if it works properly from a browser, doesn't work properly for a direct call directly from the application in the JVM (bad intermediate certificate for example). So, the service ticket validation fails and if the error page is protected, the user is sent to the CAS server which redirects him back to the application for service ticket validation and so on. Thus, the infinite loop...
I have activated SSL in live magento store.If i check this url https://www.rave-nation.com/index.php, i m getting this error "This Connection is Untrusted".I can't figure out the solution.Do you need more information to find the solution?
The SSL certificate you've installed is:
Self signed
Signed for https://localhost, not https://www.rave-nation.com
SSL certificates serve two purposes. The first is a means to encrypt the data being transferred between the client and the server. The second is functioning as a method of verifying the identity of the server you are contacting.
Certificates that are self-signed will always generate warnings to people visiting your site because the certificate has not been signed by a high authority. The higher authority, called a CA, vouch for your server being the server your visitor thinks it is.
Anyone could create an SSL certificate for the domain https://mail.google.com, for example, and self sign it. If I was to trick someone's browser to take them to my server instead of Google's when they enter https://mail.google.com in their address bar they'd get an error message saying that the connection is untrusted. This appears because the person that signed the certificate, me this case, was not trusted in the first and didn't have the authority to vouch for anyone else, as far as the web browser was concerned.
Using a certificate signed for one hostname, in your case localhost, on a website that uses another hostname, rave-nation.com, is warning the visitors that this server is claiming to be someone it is not.
Our ssl certificate recently expired, so we were issued a new one by the CA. Unfortunately, when biztalk uses this certificate to access a server, the server rejects it, giving us a 403.17 error (Expired or not yet valid).
So I checked the dates of the certificate and it seems okay. But to really check if the certificate was working, we loaded it into IE7 and tried to access the server. Doing so works.
Biztalk looks at a hard-coded location for the certificate, but we've already replaced that file with the new one.
Any idea why when Biztalk tries to access the server, it gets rejected?
Maybe Biztalk has cached your certificate?
We've found out the solution. The problem was access to the certificate and private key. When replacing the certificate, its not enough to install it. Why? Because it will only be installed under the current user.
Biztalk runs as a user: BizTalkSVC, and that account did not have permission to access the certificate.
Once it was granted permission, it ran like a charm!