SSL/TLS
Ever since the advent of RSS and Atom feeds virtually all feed XML has been served unencrypted via standard HTTP. This makes sense since RSS/Atom feeds are primarily used for non-sensitive news and information and HTTP encrypted with SSL/TLS, or HTTPS, incurs extra overhead so it traditionally has not been used unless needed. Recently, however, the heightening of privacy concerns has created a movement advocating the encryption of all HTTP traffic on the Internet. Companies as prominent as Google and Facebook are determined to make unencrypted HTTP a thing of the past. In the next few years you are likely to see more and more feeds with "https://" URLs.
HTTPS is secured with a protocol called SSL, or more recently, TLS (also known as SSL3). SSL1 and SSL2 are no longer considered secure and have been mostly phased out. When you connect to a web site with an https:// URL the server sends you a copy of its SSL/TLS Certificate, which performs two functions. First, it tells your browser or program how to encrypt communications with it, and secondly it theoretically ensures that the site is who it says it is so you don't, for instance, reveal your bank login credentials on a site that is only pretending to be your bank.
In order for the second feature of SSL/TLS to work, we need a third-party confirmation that the certificate sent to us actually belongs to the website we are accessing, otherwise we are vulnerable to a "man-in-the-middle" attack where someone inserts their own server in between us and the one we think we are accessing and sends us THEIR SSL/TLS certificate instead. Without third-party confirmation of the certificate we will think we have a secure connection (which we do) with the desired website (which we don't). To provide this third-party confirmation we have Certificate Authorities. Traditionally these have been private companies that issue SSL/TLS certificates to organizations which are digitally "signed" by both the organization and the Certificate Authority. When your browser or operating system receives a certificate from a web site it checks if the signing Certificate Authority is in a list of "trusted" signers. As more trusted Certificate Authorities come on line, OS and browser updates add these authorities to their internal list of trusted signers. EVERY SSL/TLS certificate has two signers, the owner of the web site the certificate is for, and an "authority" who says the certificate is valid for that site. If the signing authority is not recognized by the OS or browser the site is blocked unless you explicitly add an exception for that authority. These exceptions allow you access sites that use new trusted (by you) Certificate Authorities that haven't yet been added to the trusted list in your OS or browser.
Since Certificate Authorities have traditionally been commercial enterprises, there is usually a cost involved in getting them to sign off on a certificate. This cost can range from a few dollars for a certificate to secure a single site URL up to hundreds or thousands off dollars for a "multi-site" or "wildcard" certificate which can secure and verify all the web sites owned by an enterprise. These certificates are time-limited, typically a year or less, and must be periodically renewed at additional cost. Since the encryption features of SSL/TLS are useful for personal or small sites that don't require the identity confirmation aspect of a commercially purchased certificate, the SSL/TLS standard allows certificates to be "self-signed". The "owner" and "authority" signatures of a self-signed certificate are both those of the certificate owner. While this allows your communication from that site to be immune from snooping, you are trusting the issuer of the certificate to say that they have ownership control of the secured web site. This is usually perfectly legitimate, but your OS or browser will want confirmation that you consider the certificate valid, so just like for unknown Certificate Authorities, you are prompted to add an exception when you access a site secured with a self-signed certificate.
In multiFEED the downloading of feed XML is done without human intervention, so when a problem with SSL/TLS authentication is encountered, rather than asking if you want to add an exception like you see when browsing, multiFEED will just record an error message in the Hub and then fail to download the XML. The Hub error message logged will be "SSL Handshake Failure". In most cases the reason for this failure will be either a self-signed certificate, or an unknown/untrusted Certificate Authority. If you are comfortable accepting the certificate anyway, you can tell multiFEED to "relax" the rules and allow feeds using those two certificate types to download without error. Even with relaxation enabled however, all other types of SSL/TLS errors will still be displayed in the Hub and the XML won't be download. Also note that SSL/TLS Relaxation only allows the encrypted feed XML to be displayed on the front page. If the articles themselves are also encrypted with the same untrusted certificates you will still need to approve a site exception to be allowed to view them. SSL/TLS Relaxation can be set either globally, or for specific feeds, but normally it is recommended you do it at the feed level.
IMPORTANT: Prior to BlackBerry 10.2.1 it was not possible to add site exceptions for QuickView. If you encountered an untrusted SSL/TLS certificate for a site you could not load that site at all. If you are running multiFEED on a pre-10.2.1 version of BlackBerry 10 you may be able to use SSL/TLS Relaxation to get the feed XML for display, but if the article pages are also encrypted and use the same untrusted certificate you will not be able to read them even though you can see the headlines on the front page.
The Internet Security Research Group is a non-profit organization recently formed to promote the eventual universal use of SSL/TLS by issuing free certificates to organizations and individuals. Their certificate authority program has been named "Let's Encrypt", and went from private to public beta status at the beginning of December, 2015. Any individual or organization can now obtain completely free certificates recognized as trusted by most up-to-date browsers and operating systems. Although ISRG is not yet widely recognized as trusted by those browsers, they have cross-authorized their certificates with IdenTrust, which IS in most current trusted authority lists. There are only a few popular platforms and browsers that don't trust IdenTrust certificates, and unfortunately, ALL BlackBerry 10 and legacy BlackBerry operating systems/browsers are included in that few. This means that if you visit the Let's Encrypt site from your desktop or non-BlackBerry smartphone, the certificate will be trusted and the site will load unimpeded. If you visit the site from your BlackBerry device, however, you will get a warning that the certificate is from an unknown signing authority and you will need to allow an exception before you can visit the site. It also means that multiFEED is unable to download feed XML from ISRG secured sites without enabling SSL/TLS Relaxation. Hopefully future releases of BlackBerry 10 will add IdenTrust or ISRG to the trusted authority lists so this will no longer be necessary.
ISRG is unique among Certificate Authorities in that it only issues 90-day certificates and certificate owners are expected to automate the renewal process to get a new certificate approximately every 60 days without human intervention. This automation uses a clever process to ensure that certificates are only issued for sites actually controlled by those requesting them, meaning that it is safe to trust them, however this automation is not capable of verifying the identity of the requestor, just that they are in control of the contents of the site. While this may sound less safe than certificates obtained from traditional signing authorities, in practice even those traditional authorities are not equipped to positively determine the real-world identity of any but the most prominent certificate owners. Let's Encrypt has a good explanation of why confirmation of web site control is more than adequate even without being able to prove who the person or organization is in the real world.
Although still in public beta, Let's Encrypt promises to provide free trusted certificates to millions of personal and smaller business sites, and it is already trusted by most popular desktop and mobile operating systems and browsers, so you should expect to see many more sites secured with ISRG certificates as time goes on. If you want to stay informed of Let's Encrypt's progress they have an RSS feed you can view with multiFEED at https://letsencrypt.org/feed.xml, but be aware that since it uses an ISRG certificate you will need to enable SSL/TLS Relaxation.
If a certificate owner neglects to renew it in time, the certificate expires and is considered invalid so the feed generates an SSL Handshake Failure in multiFEED and will not load. Note that multiFEED's SSL/TLS Relaxation feature does NOT allow you to ignore expired certificates at this time. This may change in the future if there is enough demand from multiFEED users.