Was locked out (Read 92 times)

Last night I was not allowed to connect with RA, I was getting a message the connection was not secure and there was a danger my information, such as passwords, could be stolen. Looking up what to do about this it said the block was coming right from RA itself and the issue should resolve itself in a short time. Perhaps the block had something to do with me using my credit card to pay a water bill and also renew my RA subscription.  Anyway I was relieved this morning to see I again had access. My concern is what would have happened if I was no longer able to get to the RA website? Is there any other way to contact an administrator? Or is this a problem I should not be worrying about? If I am blocked is Eric aware of the situation and would he email me if there was an issue resolving the situation?

I had the same issue as well.  Has nothing to do with your credit card or anything on your end.  I believe it was as DW mentioned.  Eric has it resolved!  BTW,  I run 3 or 4 different browsers for different reasons and none would let me connect to RA at some point yesterday.

I have several browsers and none of them worked! I tried to investigate the problem and got the impression that the lockout was coming from RA itself, perhaps as a security measure if the certificate was no longer valid! Not sure, I'm not too savvy when it comes to computer programs! Anyway, the issue resolved itself by the next day.

Altair5 -- you did nothing wrong on your part, and there was nothing you should have done to bypass the warning from your web browser. When the site's security certificate expired, your web browser(s) was correct in not allowing access as it could no longer insure a valid SSL connection. This is all a detail of the hidden 'plumbing' of the world wide web (www), and it was a temporary glitch resolved quickly by the site's owner.

While I agree with the sentiment here, I respectfully disagree with the bolded comment. In order to understand why this is a false statement you need to understand how public key encryption (PKE) works.  PKE uses asymmetric encryption - there are two valid keys that can be used to encode/decode a message.  These key pairs are generally referred to as Private/Public keys.  These keys are essentially 2 very large numbers.  The properties are such that if I encode a message with my private key, you can decode it with the public key.  Now, how sure can you be that it is actually "me" that sent the message? That depends on two factors, how well I protect the private key and how difficult it is to calculate the private key.  We can't know how well protected the private key is, but we can make an educated guess at how difficult it is to "crack" it.  The difficulty is related to the number of bits in the key. IIRC, the current best practice is 2048 bits - earlier it was 1024, but that is no longer considered safe.  Why does this matter?  Because, the expiration dates are set based on approximately how long they think it will take to crack the private key.  Unfortunately, the expiration date may or may not represent  reality, hence the reason for increasing the size of the keys in best practices. In reality, the expiration dates can be set arbitrarily and can vary by quite a bit.  The certificate authorities (CAs) that sign a web sites certificate offer prices based on length of time before the certificate expires, e.g. Nytimes.com certificate was for 2 years and letsencrypt only validates for 90 days.

There is another use for the expiration date. W/o an expiration date, the only way to invalidate a certificate is to add it to a revocation list. Checking a revocation list is a time consuming and, compute wise, costly operation.

Notice, we still haven't talked about the security of the web site computer. It turns out that compromising the private key is more easily done by compromising the computer it is stored on. In fact, one of the more serious breaches occurred a few years ago when a CA was compromised and their private key was taken. The only way to fix this is to update every browser.

Okay, but how does that change what MT said? Well, to setup a valid SSL session you only need the Public key and the Private key.  The expiration date doesn't invalidate these two numbers. If you trust the certificate 1 second before its expiration date/time, you don't really have any reason to not trust it 1 second after its expiration date/time.  Furthermore, if the private key isn't changed (certificate renewal), the public key won't change either.  The information in the certificate will change, but not the part that you actually need to setup your SSL connection.

P.S. You can examine a sites certificate by clicking the lock icon to the left of the URL (firefox) or from the pull down menu (google).

Much like mail headers, I find them interesting to look at every now and then and in the case of mail headers more essential to examine then a virus checker as mail spoofing is way too popular, YMMV.