I have a host https://arcgis.linearbench.com
I created this certificate with win-acme (letsencrypt windows client) and the certificate is valid on other machines. However, it shows "windows does not have enough information to verify this certificate" error when I view the certificate in IIS certificate store. A browser on the server machine shows invalid certificate. And this error prevent .net application working. Is intermediate certificates missing on the server? How can I fix this?
Related
I'm fairly new to the whole certificate shebang and not a versed Linux admin.
In our company, we run a Windows domain, but we also have some CentOS servers for different services.
On one of said servers we have our ticket system, which is browser based. I want to certify it with a certificate, signed by our Windows root CA, but no matter what I do, the certificate is shown as invalid in the browser.
Funny enough, both certificates in the chain (CA -> server) are shown as valid.
I already did the following:
start certificate process from scratch
tried different certificate formats (.cer, .pem)
verified server cert with root cert
checked validity with openssl (OK)
checked SSL connection with openssl, no issues
added root cert to Linux server trusted CA store
recreated cert chain (of 2)
restarted Apache over and over
reset browser cache
tried different browser
checked DNS entries
checked, if root CA is trusted in Windows (it is)
manually installed server cert in my browser
Both the server cert and the root cert show up as valid in the browser, with the correct relation.
I'm completely lost here. Is there some key step I forgot and not one of the ~30 guides I read forgot to mention?
Any help is greatly appreciated
Your question is missing some information:
Did you check the SSL connection from outside the server?
Did you verify the RootCA cert is inside the cert-store of the server (sometimes it is rejected without error messages)?
I would check the reason for rejecting the certificate in the browser (FireFox is usually more informative than Chrome), and look for the error-code.
Reasons can be (some of which you have already verified):
Wrong certificate properties (missing the required values in the "usage" attribute)
Wrong domain name
Expired certificate
Certificate could not be verified on the client-side
See this image as an example of an error code:
https://user-images.githubusercontent.com/165314/71407838-14f55a00-2634-11ea-8a30-c119d2eb1eb1.png
I am tryng to deploy my application in net core 2.1 with a client certificate in IIS.
To do that in IIS:
autentication configuration is disable
SSL is required
And I am autenticating with my pfx in mi local, and in the server is installed the certificate with .cer in trusted root.
But all the time i am getting the 403 error:forbidden.
¿How can i fix my problem?
If someone has the code or information or a video it will be so helpfully for me
first, check the iis log for the sub status code first which is located at %SystemDrive%\inetpub\logs\LogFiles.
if the error is 403.16 Forbidden: Client Certificate Untrusted or Invalid:
It seems that IIS 8.X is not using the Certificate Trust List by default, without this list client authentication via certificates will fail with the 403.16 error and the certificate is considered untrusted.
to resolve this issue you could try to set the below DWORD registry key:
SendTrustedIssuerList = 0 (stop sending a list of trusted root certification authorities during the TLS/SSL handshake process)
ClientAuthTrustMode = 2 (Set trust mode to Exclusive CA Trust, requires that a client certificate chain to either an intermediate CA certificate or root certificate in the caller-specified trusted issuer store.)
after doing changes restart the machine.
another thing is if you are using iis require SSL setting then set the client certificate to accept:
I have a problem with a Windows 2003 server. The server is fully service packed and has all the latest windows updates.
Our server cannot connect to a certain SSL web site.
I have checked the SSL certificate of the remote third party website and it all validates successfully.
I have even checked on another Windows 2003 server and that connects and validates the certificate correctly.
The server that is failing to connect is reporting the following when trying to connect:
The remote server (url) presented a certificate that did not validate, due to RemoteCertificateChainErrors. The signature of the certificate can not be verified.
It gets a handshake but then fails to validate the certificate.
Does anyone have any ideas on what is causing this problem ?
I've cleared the CRL cache and rebooted the server accordingly but the problem still persists.
I've installed Firefox on the server and that does not have any problems connecting to the SSL url and validates the certificate correctly.
It's just the Windows OS and IE8 that have the issue and are unable to connect.
Thanks,
Chris
Is the certificate using a SHA1 or SHA2 hash algorithm? Because Windows 2003 Server does not support SHA2 unless you run the hotfix from Microsoft.
Full disclosure, I asked this question over at Ask Different (https://apple.stackexchange.com/questions/96776/always-get-a-security-error-for-internal-https-website) but didn't get much helpful feedback. I'm hoping this question fits better here.
My company recently changed an internal site to use HTTPS instead of HTTP (it is our Jira site in case that matters). From what I can tell, this site is using an internal certificate. On our work computers this certificate appears to be pre installed so the website comes up without trouble in IE, Firefox, and Chrome. However, my personal computer is a Mac (OS X 10.8.4) and I am having major troubles accessing the site through any browser. I have followed instructions to install the certificate in my Keychain and I believe I have successfully done that, but I am still not able to access the site.
When Accessing the site I Get:
Chrome: Invalid Server Certificate You attempted to reach jira.surescripts.local, but the server presented an invalid certificate.
Safari: Safari can't open the page Safari can't open the page "https://jira.local:8081/" because Safari can't establish a secure connection to the server "jira.local"
In Chrome when I view the certificate information it I see: Intermediate certificate authority. Expires: Thursday, May 21, 2015 1:19:28 PM Central Daylight Time. This certificate is valid
To make sure that it wasn't something strange with our company's VPN, I installed a Windows 7 virtual machine on my Mac and installed the certificate in Windows and am able to successfully log on to the site how I always would.
I am not much of an expert with certificates and I really don't know where to go from here. Any help would be greatly appreciated! Thanks.
It almost sounds like you need to trust a self-signed certificate? Perhaps follow: https://confluence.atlassian.com/display/SOURCETREEKB/Resolving+SSL+Self-Signed+Certificate+Errors
Sefl signed certificate always triger warnings in web browsers.
To validate a server certificate you must have in the client browser the CA certificate wich was used to sign the SSL server certificate.
Your company should create a CA cert, then create a server SSL cert. signed with the CA and put it on the web server. The clients install public part of the CA cert in "Trusted CA" certificate store. When client conect to the web server the server sent the signed SSL certificate, the client check if it is a "trusted" cert (was signed by a trusted CA) and if everithing is Ok the client doesn't show the warning.
You ended with this cert chain:
CA cert->SSL cert
CA cert public part is installed in client broser as trusted CA. SSL is put in the web server. Client validate SSL cert agaist its Trusted CA certs installed in its Certificate Stores.
It is like CyberTrus CA. You can see how you have Baltimore Cyber Trust Root and Cybertrust Public SureServer SB CA installed in your computer and when you enter into https://www.bancosantander.es/cssa/Satellite?pagename=SantanderComercial/Page/SAN_Index you can see that *.bancosantander.es certificate is valid because you are trusting in the chain.
Your company needs to create the root, then create the SSL signed by the root. The root (public part) is distributed to the client for install. The server sends the SSL to client in HTTPS protocol.
Check this link for more info.
The problem is probably the encryption protocols that your Mac and the company web site don't match up.
Safari Browsers for OS X before Safari 7 (up to 6.0.7 which was on OS X 10.8.4) use the SSL 3.0 protocol, which has vulnerabilities and is considered insecure. Most newer and well-designed web sites use TLS 1.1 and/or TLS 1.2.
Browser encryption capabilities for Safari 6.0.4
Find out from your company if that is what is set up. The same site that has the specs I linked to allow you to enter a web site, and they'll throw a battery of test transactions at it to test it's security and what will connect, but I doubt you can use that for an internal site. Ask your IT folks what encryption protocols they are using.
As a solution, I believe there are versions of Firefox and/or Chrome that can run on 10.8.4 that use TLS 1.2.
List of major browser versions that support TLS 1.2
When i tried to call .Net web service http://....using windows 7 API's
Its working fine. But if i used with same web service https://... i got
security error like There is a problem with this website's security certificate.
Help me out for this query...
You're probably using a test certificate or other certificate not supported by the phone.
If that's the case then your question is a duplicate of Making a WP7 HttWebRequest POST with an untrusted cert?
The solution to your problem is that you can't and must get a certificate from a trusted root certificate authority.
The site you're accessing needs to have a valid certificate from an issuer recognised by the platform. The latest list of these issuers I've seen is here.
push notifications from authenticated services
Note Geotrust will give you a 30 day trial certificate which is handy for testing.
Update: New documentaiton of trusted certificate issuers.