https://codesandbox.io/ seems to have an invalid SSL Cert or so my browser suggests. As such, my companies proxy services are blocking this site. Anyone have any info on why this is happening or who we could reach out to to get this resolved?
Related
Can someone kindly help me understand the following and suggest a possible fix?
Problem: Secure websocket (wss) connection fails in Chrome browser, when using a multi domain (SAN) SSL certificate
Details: We have a multi domain SSL SAN certificate that covers, say, webapp.example.com and websocket.example.com. The page https://webapp.example.com/ loads correctly (the domain is verified correctly against the SAN certificate by the browser, and a 'lock' icon is shown to indicate that the connection is secure). However, the said web application on that page also attempts to makes a connection to wss://websocket.example.com/. This connection is failing with ERR_CERT_COMMON_NAME_INVALID.
A weak hypothesis for the failure: This error is possibly because
The browser first opens an SSL connection to https://webapp.example.com after verifying webapp.example.com as a valid domain in the SAN certificate
When a connection is made to wss://websocket.example.com, the name 'websocket.example.com' does not match with the domain that has been previously verified (webapp.example.com).
Question: Is it possible to make this work? If yes, how?
Your hypothesis is wrong. The certificate validation is always done against the domain in the currently accessed URL. It is not done based on some URL previously accessed, even if the provided certificate was the same.
It is more likely that the domain you access is actually not contained in the multi-domain certificate. Note that an entry of webapp.example.com or example.com in the certificate does not cover websocket.example.com or similar in the URL.
I've tried to enable SSL on my Cloudflare account for my asset subdomains, but I see the following error in Chrome:
This site can’t provide a secure connection
a1.staging.domain.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR
And this in Firefox:
Secure Connection Failed
An error occurred during a connection to a1.staging.domain.com. Peer reports it experienced an internal error. Error code:
SSL_ERROR_INTERNAL_ERROR_ALERT
I followed this up with Cloudflare support. Turns out that this is due to the limitation that the Cloudflare issued SSL cert is only valid for a single subdomain. So *.domain.com will work, but *.staging.domain.com won't.
More info here:
https://support.cloudflare.com/hc/en-us/articles/200170566-Why-isn-t-SSL-working-for-my-site-
I have just installed a wildcard ssl certificate on a custom domain, this is working fine for any subdomain of *.example.com. I can verify that the correct ssl certificate is being issued.
However the problem is with www. which is issuing the Bluemix certificate not my own certificate.
In the browser i am getting "Your connection is not private"
This server could not prove that it is www.example.com; its security certificate is from *.eu-gb.mybluemix.net. This may be caused by a misconfiguration or an attacker intercepting your connection.
I am guessing that the problem is with Bluemix, how can i get Bluemix to serve up my certificate for www, baring in mind that it is serving up my certificate for other subdomains.
All help will be greatly recieved
I have fixed this issue, the problem was with the DNS setup.
The key piece of information for me, was that my dns was point to 2 IP's of Bluemix 5.10.124.142, and 5.10.124.141, therefore only serving up my certificate on one, and the Bluemix default certificate on the other
From googling how to add a custom domain, i added a CNAME record to point to *****.eu-gb.mybluemix.net and an A record to 5.10.124.142
This is wrong, i need to change my CNAME record to be my actual domain now.
I have a WCF web service that is setup to use Message based security. The service is using a wildcard certificate for securing the message: *.domain.com
After renewing the SSL cert, the service now throws the following error:
"Identity check failed for outgoing message. The expected DNS identity of the remote endpoint was '*.domain.com' but the remote endpoint provided DNS claim 'domain.com'. ..."
How do I fix this so the service still responds with *.domain.com as the DNS claim?
Unfortunately updating the client configs is not really an option to use the new DNS claim via the DNS identity property.
Thanks,
Mark
This is an bug in WCF. Visit the connect site and upvote if its a blocking issue. http://connect.microsoft.com/wcf/feedback/details/683178/wcf-x509-certificate-validation-only-checks-last-dnsname-in-subject-alternative-name
Turns out the issue was with the SANs list on the Wild Card Cert. The order that the domains were listed were:
*.domain.com
domain.com
WCF was basically always resolving to the last item in the SANs list. I did stumble across a few articles where Office Communicator had a similar issue. I'm not sure if this is a WCF bug or not.
My solution was to ask the Certificate Authority to generate me a wildcard cert without the SANs attribute.
The dns setting for the client is simply used to verify the certificates authenticity, so you can simply set the dns of the client to "domain.com" instead of "service.domain.com".
I got an issue from my client regarding the SSL setup for his website. I'm not familiar with the SSL certification setup process. He is saying that We have an SSL certificate for this server but I can’t tell if it’s setup properly or not.
If I open that website, firefox says Warning: Contains unauthorized content. I am seeing some details in the warning message window which are given below:
Web site: mydomain.com
Owner: This web site does not supply ownership information
Verified by: Not specified
Mainly I want to know whether the SSL certificate used for this site is valid or not. Can anybody suggest a way to check for the SSL certificate validation of a website.
Thanks
Telnet the server on port 443. If it is responding then it is a certificate problem
To install certificate
Check this