I currently have an app running with a Cisco virtual Wireless Lan Controller, all works fine except we get some error messages regarding SHA1 certificates, when I'm looking for SHA2 support the cisco release notes tell me that SHA2 certificates are not supported, even in the latest 8.2.100.0 release. Can anyone confirm this, or better yet does anyone have a fix for this?
It is not supported on a virtual WLC:
http://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn82.html#pgfId-1319001
Related
I am using Wso2-emm 2.2.0 in my ubuntu machine and currently I am just exploring the web console for my future project. While going through Configuration Management > Certificate Configurations, I am not able to find the use of uploading certificates (in .pem format) in the server.
If any such use is there please tell me because my project needs installation of X.509 digital certificates on android, ios and windows device for achieving BYOD implementation.
Thanks in advance and help is appreciated
gaurav sharma
This is used to enroll devices using mutual SLL.
This feature is only allowed for android devices only.
Having an issue with my SSL certificate. Often it seems to work fine, but sometimes the user's browser throws up a warning that it is not trusted.
I know very little about SSL certificates, but here is some information that may or may not be relevant:
URL: demo.EnterpriseJazz.com
It is a wild card certificate because
the application uses subdomains (one subdomain per registered organization Example: BobsLawnCare.EnterpriseJazz.com)
The certificate was cheap for a wild card certificate, I paid around $50 for it if I remember correctly. I believe I got it from a cheap re-seller.
The server is located in my house on a Verizon FIOS business internet connection. It is not in a data center.
Seems to work fine with:
Safari on my new Macbook Pro
Chrome on my new Macbook Pro
Firefox on my windows machine
Microsoft Edge on my windows machine
Internet Explorer on my windows machine
Opera on my windows machine
Firefox on my Linux machine (CentOS)
Not trusted with:
Chrome on my iPhone 6s
Safari on my iPhone 6s (screen shots below)
Have a look at the SSLLabs report for this site. Apart from a shockingly insecure setup you will notice:
This server's certificate chain is incomplete.
This means that the client has not enough information to build the trust path to the root certificate and thus can not accept the certificate as trusted.
However a desktop browser will attempt to work around such setup problems by trying to fill in the missing chain certificates, i.e. downloading these from the web or using cached certificates from earlier connections to other clients. But apart from the desktop browsers most other clients will not do it and thus fail.
I had the exact same issue.
After futzing with every nook and cranny of my SSL and http setups, I finally realized "How silly I was to not check the URL first!"
My browser had been connecting to the regular non-trusted site (http://example.com) and I had blindly assumed that the broken lock icon meant something was wrong with my cert installation. Duh!
Modern browsers hiding the actual protocol letters behind a pretty icon or user-friendly message that conflates two issues into one - that didn't help.
My suggestion would be to first make sure you're hitting the https version of your site. If not, your first step to the solution is to create an automatic redirect of all http to https.
I hope getting to this post first helps at least 1% of those who had this problem. I'm in that 1%
first question.
I recently put kubuntu onto my chromebook via crouton, which was painless and awesome. However, it did necessitate putting it into developer mode. For some reason, this has removed ChromeOS's ability to authenticate SSLs for a couple of sites I use for work (but not all of them). I prodded the sysadmin, and he says the problem is the NSS library. Specifically:
It is a problem with the NSS library version on the users OS. You can
by pass the problem by starting Chrome with;
$ google-chrome-stable --ssl-version-max=tls1.1
I tried running that command (with and without the $) in Crosh, shell, and even bios command prompt. Nope (command not found, or some variation there of). This page seems to suggest that NSS isn't favoured, but the sysadmin is unable or unwilling to change the protocol to OpenSSL. So I'm left with trying to install NSS support onto my post-crouton, dev-mode chromebook. Problem is, I have no idea how to do that. Worst case scenario, I can move my work environment totally from ChromeOS into the newly installed Kubuntu instance, but I'd rather not because ChromeOS is just such a pleasure to work on, for browser based work.
Does anyone know how to get NSS protocol SSLs working on dev-mode ChromeOS?
you cannot re-run chrome from within chrome, so that command won't help.
NSS/OpenSSL aren't protocols, they're libraries that implement protocols. Chrome OS uses NSS for some certificate management, but it uses OpenSSL (actually BoringSSL) for all network communication.
putting Chrome OS into dev mode though should not change its behavior at all when it comes to network protocol negotiation. without more details, it's hard to guess at the issue.
A little while ago we received an email from the Azure Team regarding an upcoming TLS/SSL cipher suit update, kicking in after July 18th with the following instruction:
You can check whether the clients that access your web apps will still function correctly by testing them against https://testsslclient.trafficmanager.net/. Your client is compatible if you receive a 200 HTTP status—the page will display a “SSL client test complete!” message.
After testing our standard clients it looks like IE7 and IE8 fail the test on XP SP3 (Chrome still works).
Does anybody else have results of what clients are expected to fail? (It would have been nice if the Azure Team would have provided a list of expected incompatibilities).
Also: the test page uses an SHA2 certificate. We are still using SHA1 on some sites, due to be updated eventually. Does anybody know if the update will have any impact on SHA1 certificates?
Related link
Yes, XPSP3 IE 7/8 will fail because they don't support any of the ciphers that will be on the updated list. I don't think we have a list of clients that will / will not work, because the list is quite large ... you have to worry about embedded devices like PoS terminals etc, and not just browsers.
SHA-1 certificates will still be supported in Azure WebApps, although some browsers like Chrome will complain about obsolete cryptography etc.
We have repeated our tests today and IE7 and IE8 on XPSP3 now pass the client test at https://testsslclient.trafficmanager.net.
We assume the implementation of the TLS/SSL cipher suit has been updated to allow for this now...
It is said that openssl are widely used, however, as far as I know, the most popular browsers seem not use openssl, instead, they use other SSL libraries like:
NSS (for all firefox and chrome in Linux)
SChannel (for browsers in Windows)
Secure Transport (for browsers in Mac OS X).
Am I right? Or is there any concept I'm taking wrong?
Thanks.
OpenSSL is widely used in web server, according to netcraft survey (http://news.netcraft.com/archives/2015/06/25/june-2015-web-server-survey.html) it can be over 60% of all web servers : Apache with mod_ssl, Google and Nginx. For browser it is just not widely used.