Logging into BT mail

As a BT customer I can see there is nothing wrong with the BT email web site certificate it could be that the OP is not connected to the BT mail website
You are too late to see the problem yourself as BT already fixed it. See the screen shots above.
 
Yes I understand that, but the system doesn't automatically accept any old certificate just because you once accepted one
No. But every time the cert changes you will be re-prompted. You do not get these re-prompts if the certificate is a valid one and is just being updated/renewed.
Getting into the habit of accepting invalid certs is a really bad thing to do for normal users. I don't even do it myself and I understand this stuff and make a living out of it.

If you want to do it yourself, have at it. But please don't recommend others do it and open themselves to potential issues down the line.
 
Your browser is warning you that it can't validate who it is connecting to. They aren't providing a valid certificate to prove they are who they say they are.

In this case, it looks like it was a misconfiguration by BT. But it could also have been that someone had hacked the BT webmail server, or changed the domain name routing and you're actually connecting to a fake site that's skimming off your login details.

Unless you're absolutely sure you can trust the site you're connecting to, don't override the certificate warning.
 
You do not get these re-prompts if the certificate is a valid one and is just being updated/renewed.
Browsing the public internet, It’s certainly a good idea to take the certificate error as a reason to investigate the cause or wait.
🤔 a hyperlink with “http” written instead of ”https” does that get the same cert error or just an “insecure” warning? Can’t remember.

If you’re on local internet (intranet) and need to get to a product’s web gui there could be a certificate warning that means you may have to manually add the product’s web GUI to the “known safe sites” list in a browser’s Internet Settings > Security
Some companies’ site security policy will mean the product manufacturer will have to provide a dummy certificate to comply. AWS Elemental are a manufacturer with an example of this scenario.
TWIS = That's what I said
Thought it was funny/ironic referring someone to older posts but missing the previous posts are doing the same 🤪🤣
 
Browsing the public internet, It’s certainly a good idea to take the certificate error as a reason to investigate the cause or wait.
Exactly this. As most people do not understand and cannot diagnose the cause, the wait option is ALWAYS the best option.

SSL is not an easy subject to get competent in, as such I would recommend that no one forces the browser to accept an invalid cert.
 
Was getting the warning as well last night , for BT email login , MyBT login , but was ok to go to Bt.Com all back to normal this a.m. interesting to find out why :)(y)

Subscribers  do not see these advertisements

 
Was getting the warning as well last night , for BT email login , MyBT login , but was ok to go to Bt.Com all back to normal this a.m. interesting to find out why :)(y)
Two different certificates it’s probably backend work that was being carried out. there are some guesses as you can see to possible causes but you will probably never know as BT does not publish details of its network or all server locations etc.

One thing you can be sure of it’s a pretty secure network and well engineered with a host of highly qualified network designers and engineers.
 
Two different certificates it’s probably backend work that was being carried out. there are some guesses as you can see to possible causes but you will probably never know as BT does not publish details of its network or all server locations etc.
Appears to be the same certificate. If you inspect the cert you will see that the bt.com certificate also includes multiple alt-names including (currently) home.bt.com

Yesterday for a period home.bt.com was missing.

As you can see from the validity period this is not a new certificate as it was issued almost a year ago.

What they did was install a different cert on the server for home.bt.com that didnt' have the alt name home.bt.com in it.
1658423306311.png


One thing you can be sure of it’s a pretty secure network and well engineered with a host of highly qualified network designers and engineers.
And yet they still managed to make this cock up which could be avoided by good quality systems automation such as used by this very forum. Check the cert for MHF and you will see it gets renewed every 3 months without issues. The certificate is set to expire every 3 months for security reasons.
 
Two different certificates it’s probably backend work that was being carried out. there are some guesses as you can see to possible causes but you will probably never know as BT does not publish details of its network or all server locations etc.

One thing you can be sure of it’s a pretty secure network and well engineered with a host of highly qualified network designers and engineers.
Highly qualified engineers... that didn't pick up the failed certificate. Good practice would have had automated deployment checks to pick up this kind of thing.


Also, it doesn't matter how secure the server is. If one of the domain name servers has been hijacked or had poisoned records inserted, the certificate might be failing because you aren't looking at BT's web server, you're looking at a fake masquerading as the BT webmail site, looking to skim your login details.

Point is, you don't know why the certificate check is failing. So it's generally a bad idea to override the warnings.
 
Also, it doesn't matter how secure the server is. If one of the domain name servers has been hijacked or had poisoned records inserted, the certificate might be failing because you aren't looking at BT's web server, you're looking at a fake masquerading as the BT webmail site, looking to skim your login details.
Exactly this. Another great example of why it is a bad move to force your browser to accept a cert. Nice one Guigsy but it was Aireworth not Coolcats who was recommending over riding the browser checks.
 
Appears to be the same certificate. If you inspect the cert you will see that the bt.com certificate also includes multiple alt-names including (currently) home.bt.com

Yesterday for a period home.bt.com was missing.

As you can see from the validity period this is not a new certificate as it was issued almost a year ago.

What they did was install a different cert on the server for home.bt.com that didnt' have the alt name home.bt.com in it.
View attachment 644063


And yet they still managed to make this cock up which could be avoided by good quality systems automation such as used by this very forum. Check the cert for MHF and you will see it gets renewed every 3 months without issues. The certificate is set to expire every 3 months for security reasons.
"They" who is they? possibly a contractor and yes I understand certificates so the OP's computer did the right thing

One thing about outside observation is it is a little like watching football you can see the ball missed the goal but what you or anyone doesn't know was the intent......

Subscribers  do not see these advertisements

 
Stupid question alert... What happens if an email client is used such as Thunderbird please?
 
I had exactly the same issue last night for 4 hours then all was well, had me a bit worried though when it says it was an unsafe connection
 
"They" who is they? possibly a contractor and yes I understand certificates so the OP's computer did the right thing

One thing about outside observation is it is a little like watching football you can see the ball missed the goal but what you or anyone doesn't know was the intent......
No idea what you are getting at here.
They = BT
Outside observation. they screwed up and broke their web based login service. Ball missed the goal big time. I am sure the intent was not to miss the goal.
 
Stupid question alert... What happens if an email client is used such as Thunderbird please?
Thunderbird will connect via a different method than the webmail. I think it'll still check certificates and complain if there's an issue. From what Gromett found, it looks like it was probably unaffected.
 
Stupid question alert... What happens if an email client is used such as Thunderbird please?
As I said in previous post different services use different ports and can load different certificates. If one is broken it doesn't necessarily mean they will all be broken. They are totally independent.

The reason for this is that the app likely logs onto a mail server (IMAP: on port 143) to read the email where as the web browser logs onto a web server (HTTPS on port 443).
BT have probably got the right certificate on IMAP and only screwed it up on HTTPS.

Guigsy was correct on this point.

Subscribers  do not see these advertisements

 
No idea what you are getting at here.
They = BT
Outside observation. they screwed up and broke their web based login service. Ball missed the goal big time. I am sure the intent was not to miss the goal.
Ok so now we are stating to get somewhere, we are all human and we all make mistakes. So BT an employee or a contractor made a change to a system, that system for whatever reason did not include the text or certificate as required. But given the complexities of any large complex system or network stuff happens.

‘ they screwed up and broke their web based login service’ is value ladened judgemental statement no one knows who what or why if it was human error maybe the individuals Cat had just died or worse. it was fixed just as my temperature sensor on my door mirror has been but I don’t go around saying Fiat screwed up.

It is also clear that the web browsers where doing what they needed to do in alerting there was an issue so overall the systems work as intended pretty neat eh. 🤓
 
Ok so now we are stating to get somewhere, we are all human and we all make mistakes. So BT an employee or a contractor made a change to a system, that system for whatever reason did not include the text or certificate as required. But given the complexities of any large complex system or network stuff happens.
You clearly have never done this type of work. The system should be automated so that errors like this CANNOT happen. BT therefore screwed up. They either have a broken automation system or do it manually.
 
You clearly have never done this type of work. The system should be automated so that errors like this CANNOT happen. BT therefore screwed up. They either have a broken automation system or do it manually.
It was almost certainly an error created by a human. But reality is messy. Automated deployments and tests aren't smart. A minor change that a developer or maintenance person made could have had unintended consequences and caused a condition that the tests didn't pick up. Even the best DevOps implementations aren't bullet proof. This issue will probably trigger them to put a whole new load of tests in the system so this particular failure won't happen again. Which is great until another inventive human accidentally finds another way to break the system.
 
You clearly have never done this type of work. The system should be automated so that errors like this CANNOT happen. BT therefore screwed up. They either have a broken automation system or do it manually.
😂 automated systems never make an error thats a funny one Gromett.
 
It was almost certainly an error created by a human. But reality is messy. Automated deployments and tests aren't smart. A minor change that a developer or maintenance person made could have had unintended consequences and caused a condition that the tests didn't pick up. Even the best DevOps implementations aren't bullet proof. This issue will probably trigger them to put a whole new load of tests in the system so this particular failure won't happen again. Which is great until another inventive human accidentally finds another way to break the system.
The automated deployment test for this is straight forward. Does the cert contain an alt name that matches the hostname? Simple straight forward test to prevent an invalid cert being activated on a host.

Subscribers  do not see these advertisements

 
😂 automated systems never make an error thats a funny one Gromett.
Automated systems do not make errors. Errors can be made in the design of an automated system but an automated system will always do exactly as it is told.

Their automated system was badly designed as it allowed an invalid cert to be installed and activated.

In a test script you extract the SAN from the cert you want to install using.
SAN=`openssl x509 -noout -text -in cert.pem | grep DNS:`
You then check to see if the hostname you are installing on is contained in SAN.

This is a simple check to ensure you do not install an invalid certificate onto the system.

Other checks using similar commands check to ensure you are not installing an expired cert, that todays date is past the valid from setting, and that it meets a minimum algorithm (for example sha256WithRSAEncryption)
If any of these fail it should not deploy and report the error to a responsible party.

The error they made was not including this simple test in their deployment system. It was not an error in their automated system.
 
Automated systems do not make errors. Errors can be made in the design of an automated system but an automated system will always do exactly as it is told.

Their automated system was badly designed as it allowed an invalid cert to be installed and activated.

In a test script you extract the SAN from the cert you want to install using.
SAN=`openssl x509 -noout -text -in cert.pem | grep DNS:`
You then check to see if the hostname you are installing on is contained in SAN.

This is a simple check to ensure you do not install an invalid certificate onto the system.

Other checks using similar commands check to ensure you are not installing an expired cert, that todays date is past the valid from setting, and that it meets a minimum algorithm (for example sha256WithRSAEncryption)
If any of these fail it should not deploy and report the error to a responsible party.

The error they made was not including this simple test in their deployment system. It was not an error in their automated system.
That would be one way of doing it. But what if some bright spark changed whatever the method that the script was using to identify which hostnames it should be looking for to do the check against? Maybe, in some distant past, everyone agreed to use a fixed name in a key parameter that the automated scripts then picked up in their testing. And a newer dev decided to refactor some ancient code and altered that bit, unknowingly deleting the check. Or it might have been that there have been several changes over time that mean the test disappeared a while ago, but nobody noticed because the deployments kept working. Maybe they are relying too heavily on tests in a staging environment and something wasn't perfectly mirrored in production... there's a million ways that this could happened. DevOps reduces a lot of risks. But it also creates the risk that the human assumes everything is OK because all the lights went green and they log off and head home for the weekend.

Most of the projects I've worked on have had too much physical presence (real world sensors, robots and ancient software products that doesn't have nice APIs and scripting) to be able to completely rely on automated deployment tests. So I've always ended up doing manual sense checks. Pretty frequently, my old school testing will uncover issues in software that -could- have been picked up by an automated test, but nobody thought to include it. But it became blatantly obvious it was borked when the code hit the real world.

Example: new software was developed for some user terminals. It passed automated tests that, amongst a few hundred other things, checked a test user could log in. The script was poking input directly into form text boxes. IT triumphantly declared the new software was deployed. I went to do my testing. Came back 5 minutes later to tell them to roll-back... the text boxes were off the edge of the screen when viewed from the low-res terminals on the shop floor, so nobody could log on.
 
Automated systems do not make errors. Errors can be made in the design of an automated system but an automated system will always do exactly as it is told.

Their automated system was badly designed as it allowed an invalid cert to be installed and activated.

In a test script you extract the SAN from the cert you want to install using.
SAN=`openssl x509 -noout -text -in cert.pem | grep DNS:`
You then check to see if the hostname you are installing on is contained in SAN.

This is a simple check to ensure you do not install an invalid certificate onto the system.

Other checks using similar commands check to ensure you are not installing an expired cert, that todays date is past the valid from setting, and that it meets a minimum algorithm (for example sha256WithRSAEncryption)
If any of these fail it should not deploy and report the error to a responsible party.

The error they made was not including this simple test in their deployment system. It was not an error in their automated system.
All hypothetical Gromett as with any system unless you know the architecture of the systems involved it’s all guessing you could be right you could be wrong. 🤓

The only certainty was the end point reporting an error once reported the maintenance teams fixed the issue

And yes Automated systems do make mistakes. From Microsoft SAP Apple Sybase Oracle etc they have all had automated systems errors
 
That would be one way of doing it. But what if some bright spark changed whatever the method that the script was using to identify which hostnames it should be looking for to do the check against? Maybe, in some distant past, everyone agreed to use a fixed name in a key parameter that the automated scripts then picked up in their testing. And a newer dev decided to refactor some ancient code and altered that bit, unknowingly deleting the check. Or it might have been that there have been several changes over time that mean the test disappeared a while ago, but nobody noticed because the deployments kept working. Maybe they are relying too heavily on tests in a staging environment and something wasn't perfectly mirrored in production... there's a million ways that this could happened. DevOps reduces a lot of risks. But it also creates the risk that the human assumes everything is OK because all the lights went green and they log off and head home for the weekend.

Most of the projects I've worked on have had too much physical presence (real world sensors, robots and ancient software products that doesn't have nice APIs and scripting) to be able to completely rely on automated deployment tests. So I've always ended up doing manual sense checks. Pretty frequently, my old school testing will uncover issues in software that -could- have been picked up by an automated test, but nobody thought to include it. But it became blatantly obvious it was borked when the code hit the real world.

Example: new software was developed for some user terminals. It passed automated tests that, amongst a few hundred other things, checked a test user could log in. The script was poking input directly into form text boxes. IT triumphantly declared the new software was deployed. I went to do my testing. Came back 5 minutes later to tell them to roll-back... the text boxes were off the edge of the screen when viewed from the low-res terminals on the shop floor, so nobody could log on.
I typed in a big response but we are getting further and further away from my original point.

I was agreeing with you when you said this.
Highly qualified engineers... that didn't pick up the failed certificate. Good practice would have had automated deployment checks to pick up this kind of thing.

They either don't have good automation or their automation sucks... As for highly qualified engineers? I doubt highly qualified engineers made such a basic mistake of installing an invalid cert manually.

This is not about devops. This is a purely operations thing. Your point about your custom sofware and text boxes off screen is perfectly valid. However, we are not talking about normal software here we are talking about primary systems stuff. This does not change. Changes to this would break stuff across the internet in major ways. The openssl command, the hostname command are just two examples of extremely stable system commands that cannot be changed because too much stuff relies on it.
With that in mind any automation system would not be altered by some bright spark changing how the hostname was detected. The hostname command is all that is needed and the openssl command gives a standardised output.

My points are this.
The tools used to test and deploy certs are standardised and do not change.
Their output is well understood and comprehensive.
Writing tests against these outputs is simple
Either the tests weren't done or someone overrode them.
 
But what if some bright spark changed whatever the method that the script was using to identify which hostnames it should be looking for to do the check against?
Just to clarify. The hostname command is a standard system command and returns the hostname and nothing else. This command is probably older than me.

Subscribers  do not see these advertisements

 

Join us or log in to post a reply.

To join in you must be a member of MotorhomeFun

Join MotorhomeFun

Join us, it quick and easy!

Log in

Already a member? Log in here.

Latest journal entries

Back
Top