Despite what you may think, you actually were using HTTPS. This is perhaps an over-simplification, but here's more or less what happened:
When you accessed the website with http:// as the protocol in your Address Bar, you effectively told your computer "Make a request for this webpage, from this server, and send that request to port 80 on the server". If the server is configured to allow access via plain HTTP (apparently, it was), the server will respond and your session (unless re-directed) will continue over HTTP.
By changing the protocol to https://, you instead directed your computer to attempt an SSL/TLS handshake via port 443 on the server and then send the HTTP requests through that tunnel. Obviously, this worked or you would not have been able to access the page. Since the SSL/TLS connection was successful, that meant that all subsequent HTTP requests sent through that tunnel would be secured from casual eavesdropping (e.g.: via Wireshark).
But now, you ask, what about that nasty red slash through https, and the "x" on the lock? These indicators do not mean that the SSL/TLS connection was unsuccessful, or that your communications to the website are not encrypted. All these negative indicators mean is that the website is not signed by an authority your browser recognizes. This is often the case for the web interfaces on SOHO networked equipment, business applications, or websites where the administrator has chosen to use a self-signed certificate instead of purchasing one from a well-recognized authority (e.g.: VeriSign).
This is analogous in some ways to selling alcohol in a jurisdiction where such sales are age-restricted. Since I don't know all the intricacies of the real-world laws, let's say for the sake of argument that the law only goes so far as to say it is illegal to sell alcohol to a person who is younger than a given age. What the law in this hypothetical case does not specify is whether you are required to check I.D. prior to a sale, or which forms of I.D. are considered to be valid proofs of age at time of sale. Authoritative proof of the buyer's age is only ultimately required in court if the legality of the sale is ever challenged. However, it is still of course a good idea to check I.D.s on every sale just to be safe.
Here, you are a clerk at a convenience store in the great state of Comodo. Most of your customers will be fellow Comodoans, and so you are naturally able to easily recognize and verify their I.D.s which are issued by the Comodo Government.
One day though, you get a customer from the distant state of VeriSign. What do you do now? Fortunately, your store has a book called Trusted Root Certificates which has pictures and tips on how to verify I.D.s issued from various states in your country. You check your book, compare the customer's I.D. to the relevant photograph and notes, and judge that the I.D. is indeed issued by an authority trusted by your store. Given this, you can now trust that the information on the I.D. (particularly, stating the customers identity and age) is accurate, and therefore be comfortable in knowing that you are making a legal sale.
On another day, a customer comes in from overseas. His name is Drupal, and he hails from the land of DigiNotar. He says he is old enough to buy alcohol, and his DigiNotarian Government I.D. concurs with his statement. However, your Trusted Root Certificates book does not have any information to help you verify an I.D. from his country. What do you do here?
Strictly speaking, by the letter of the law in this hypothetical country, your sale would still be legal if your customer is in fact as old as he says he is. You could choose to assume he is telling the truth and, if he actually is, go on with your life without ever being convicted of any crime related to that action.
But, without any documentation from an authority you recognize, you are still taking the risk that he is not telling the truth. It's very possible that he is not of the proper age, despite what he and his I.D. may claim. In this case, the sale will still be completed. The product will still only be transferred between you and your customer (not immediately available to anyone else, unless your customer chooses to distribute it), but now the problem is that the alcohol has been given to someone who legally should not have it - and you could be in trouble for this.
TL;DR: As long as your browser shows https:// as the protocol, you can be assured that the data in your communications are secured between your computer and some endpoint. If there's any warning signs around that https:// area though, that means that the browser does not trust that endpoint to be what it claims to be. It is then up to you to decide whether you trust the endpoint's claims to identity enough to transfer sensitive data over the connection. The connection is still secure in the sense that nobody between you and the other end of the HTTPS connection can sniff the data, but you are taking the chance that the other end isn't what it claims to be.
UPDATE: Some browsers are now beginning to incorporate checks on the cipher suites and other properties of the HTTPS connection, and providing warnings accordingly. In these cases, the above still applies, but you should be aware that it will be easier for an eavesdropper or Man-in-the-Middle to break that security than if the site used stronger encryption protocols.
