Akamai Cert Issues today
e noticed SSL warnings based around Akamai's "a248.e.akamai.net" certificate today. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015. Wonder why we are noticing the errors from multiple points on the internet now? Jim Witherell Cincinnati OH
Certificate validates for me (on chrome) And also https://pulse.turbobytes.com/results/560c589decbe400bf8001bbf/ . Tested from multiple points. The tool does TLS validations. Unrelated: That endpoint seems to be blackholed from china... What common name do you see in the cert given to you? I see " a248.e.akamai.net" which is valid. -Sajal On Thu, Oct 1, 2015 at 4:16 AM Jim Witherell via Outages < outages@outages.org> wrote:
e noticed SSL warnings based around Akamai's "*a248.e.akamai.net <http://a248.e.akamai.net>*" certificate today. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015. Wonder why we are noticing the errors from multiple points on the internet now?
Jim Witherell
Cincinnati OH _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
It's not a problem with the CN or the SANs on the certificate. The issue is a broken trust path. My guess would be they're using a new root CA that doesn't have good coverage yet. On Wed, Sep 30, 2015 at 2:52 PM, Sajal Kayan via Outages < outages@outages.org> wrote:
Certificate validates for me (on chrome) And also https://pulse.turbobytes.com/results/560c589decbe400bf8001bbf/ . Tested from multiple points. The tool does TLS validations. Unrelated: That endpoint seems to be blackholed from china...
What common name do you see in the cert given to you? I see " a248.e.akamai.net" which is valid.
-Sajal
On Thu, Oct 1, 2015 at 4:16 AM Jim Witherell via Outages < outages@outages.org> wrote:
e noticed SSL warnings based around Akamai's "*a248.e.akamai.net <http://a248.e.akamai.net>*" certificate today. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015. Wonder why we are noticing the errors from multiple points on the internet now?
Jim Witherell
Cincinnati OH _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
_______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
Another item: go to sslshopper.com and click "ssl checker" and type in www.Cincinnati.com or www. and see that the chain is broken. Sent from Yahoo Mail on Android From:"Jeff Walter" <jwalter@weebly.com> Date:Wed, Sep 30, 2015 at 5:55 PM Subject:Re: [outages] Akamai Cert Issues today It's not a problem with the CN or the SANs on the certificate. The issue is a broken trust path. My guess would be they're using a new root CA that doesn't have good coverage yet. On Wed, Sep 30, 2015 at 2:52 PM, Sajal Kayan via Outages <outages@outages.org> wrote: Certificate validates for me (on chrome) And also https://pulse.turbobytes.com/results/560c589decbe400bf8001bbf/ . Tested from multiple points. The tool does TLS validations. Unrelated: That endpoint seems to be blackholed from china... What common name do you see in the cert given to you? I see "a248.e.akamai.net" which is valid. -Sajal On Thu, Oct 1, 2015 at 4:16 AM Jim Witherell via Outages <outages@outages.org> wrote: e noticed SSL warnings based around Akamai's "a248.e.akamai.net" certificate today. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015. Wonder why we are noticing the errors from multiple points on the internet now? Jim Witherell Cincinnati OH _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
Agree with Chris Swingler https://cincinnati.com/ Gives NET::ERR_CERT_COMMON_NAME_INVALID . That does not appear to be chain issues. Its because cincinnati.com is not in the common name or in the SAN. The certificate provided is valid only for CN : a248.e.akamai.net SAN:- DNS Name: a248.e.akamai.net DNS Name: *.akamaihd.net DNS Name: *.akamaihd-staging.net DNS Name: *.akamaized.net DNS Name: *.akamaized-staging.net Looks like someone messed up DNS config, or forgot to add some SANs. https://pulse.turbobytes.com/results/560c5bb9ecbe400bf8001bc6/ -Sajal On Thu, Oct 1, 2015 at 5:00 AM Jim Witherell <jawitherell@yahoo.com> wrote:
Another item: go to sslshopper.com and click "ssl checker" and type in www.Cincinnati.com or www. and see that the chain is broken.
Sent from Yahoo Mail on Android <https://overview.mail.yahoo.com/mobile/?.src=Android> ------------------------------ *From*:"Jeff Walter" <jwalter@weebly.com> *Date*:Wed, Sep 30, 2015 at 5:55 PM
*Subject*:Re: [outages] Akamai Cert Issues today
It's not a problem with the CN or the SANs on the certificate. The issue is a broken trust path. My guess would be they're using a new root CA that doesn't have good coverage yet.
On Wed, Sep 30, 2015 at 2:52 PM, Sajal Kayan via Outages < outages@outages.org> wrote:
Certificate validates for me (on chrome) And also https://pulse.turbobytes.com/results/560c589decbe400bf8001bbf/ . Tested from multiple points. The tool does TLS validations. Unrelated: That endpoint seems to be blackholed from china...
What common name do you see in the cert given to you? I see " a248.e.akamai.net" which is valid.
-Sajal
On Thu, Oct 1, 2015 at 4:16 AM Jim Witherell via Outages < outages@outages.org> wrote:
e noticed SSL warnings based around Akamai's "*a248.e.akamai.net <http://a248.e.akamai.net>*" certificate today. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015. Wonder why we are noticing the errors from multiple points on the internet now?
Jim Witherell
Cincinnati OH _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
_______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
Question: was www.irs.gov ever on https ? On Thu, Oct 1, 2015 at 5:05 AM Sajal Kayan <sajal83@gmail.com> wrote:
Agree with Chris Swingler
https://cincinnati.com/ Gives NET::ERR_CERT_COMMON_NAME_INVALID . That does not appear to be chain issues. Its because cincinnati.com is not in the common name or in the SAN.
The certificate provided is valid only for
CN : a248.e.akamai.net SAN:- DNS Name: a248.e.akamai.net DNS Name: *.akamaihd.net DNS Name: *.akamaihd-staging.net DNS Name: *.akamaized.net DNS Name: *.akamaized-staging.net
Looks like someone messed up DNS config, or forgot to add some SANs.
https://pulse.turbobytes.com/results/560c5bb9ecbe400bf8001bc6/
-Sajal
On Thu, Oct 1, 2015 at 5:00 AM Jim Witherell <jawitherell@yahoo.com> wrote:
Another item: go to sslshopper.com and click "ssl checker" and type in www.Cincinnati.com or www. and see that the chain is broken.
Sent from Yahoo Mail on Android <https://overview.mail.yahoo.com/mobile/?.src=Android> ------------------------------ *From*:"Jeff Walter" <jwalter@weebly.com> *Date*:Wed, Sep 30, 2015 at 5:55 PM
*Subject*:Re: [outages] Akamai Cert Issues today
It's not a problem with the CN or the SANs on the certificate. The issue is a broken trust path. My guess would be they're using a new root CA that doesn't have good coverage yet.
On Wed, Sep 30, 2015 at 2:52 PM, Sajal Kayan via Outages < outages@outages.org> wrote:
Certificate validates for me (on chrome) And also https://pulse.turbobytes.com/results/560c589decbe400bf8001bbf/ . Tested from multiple points. The tool does TLS validations. Unrelated: That endpoint seems to be blackholed from china...
What common name do you see in the cert given to you? I see " a248.e.akamai.net" which is valid.
-Sajal
On Thu, Oct 1, 2015 at 4:16 AM Jim Witherell via Outages < outages@outages.org> wrote:
e noticed SSL warnings based around Akamai's "*a248.e.akamai.net <http://a248.e.akamai.net>*" certificate today. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015. Wonder why we are noticing the errors from multiple points on the internet now?
Jim Witherell
Cincinnati OH _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
_______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
https://news.ycombinator.com/item?id=6872318 www.irs.gov was never on https . The error is bad user experience, but its common for all CDNs who listen on 443 regardless if customer has ssl activated or not. -Sajal On Thu, Oct 1, 2015 at 5:14 AM Sajal Kayan <sajal83@gmail.com> wrote:
Question: was www.irs.gov ever on https ?
On Thu, Oct 1, 2015 at 5:05 AM Sajal Kayan <sajal83@gmail.com> wrote:
Agree with Chris Swingler
https://cincinnati.com/ Gives NET::ERR_CERT_COMMON_NAME_INVALID . That does not appear to be chain issues. Its because cincinnati.com is not in the common name or in the SAN.
The certificate provided is valid only for
CN : a248.e.akamai.net SAN:- DNS Name: a248.e.akamai.net DNS Name: *.akamaihd.net DNS Name: *.akamaihd-staging.net DNS Name: *.akamaized.net DNS Name: *.akamaized-staging.net
Looks like someone messed up DNS config, or forgot to add some SANs.
https://pulse.turbobytes.com/results/560c5bb9ecbe400bf8001bc6/
-Sajal
On Thu, Oct 1, 2015 at 5:00 AM Jim Witherell <jawitherell@yahoo.com> wrote:
Another item: go to sslshopper.com and click "ssl checker" and type in www.Cincinnati.com or www. and see that the chain is broken.
Sent from Yahoo Mail on Android <https://overview.mail.yahoo.com/mobile/?.src=Android> ------------------------------ *From*:"Jeff Walter" <jwalter@weebly.com> *Date*:Wed, Sep 30, 2015 at 5:55 PM
*Subject*:Re: [outages] Akamai Cert Issues today
It's not a problem with the CN or the SANs on the certificate. The issue is a broken trust path. My guess would be they're using a new root CA that doesn't have good coverage yet.
On Wed, Sep 30, 2015 at 2:52 PM, Sajal Kayan via Outages < outages@outages.org> wrote:
Certificate validates for me (on chrome) And also https://pulse.turbobytes.com/results/560c589decbe400bf8001bbf/ . Tested from multiple points. The tool does TLS validations. Unrelated: That endpoint seems to be blackholed from china...
What common name do you see in the cert given to you? I see " a248.e.akamai.net" which is valid.
-Sajal
On Thu, Oct 1, 2015 at 4:16 AM Jim Witherell via Outages < outages@outages.org> wrote:
e noticed SSL warnings based around Akamai's "*a248.e.akamai.net <http://a248.e.akamai.net>*" certificate today. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015. Wonder why we are noticing the errors from multiple points on the internet now?
Jim Witherell
Cincinnati OH _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
_______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
For instance go to https://www.irs.gov and https://Cincinnati.com and you should see it. We saw it here in the office, and at a few home employees tried it, and on cell phones from vzw and AT&T to. Sent from Yahoo Mail on Android From:"Sajal Kayan" <sajal83@gmail.com> Date:Wed, Sep 30, 2015 at 5:52 PM Subject:Re: [outages] Akamai Cert Issues today Certificate validates for me (on chrome) And also https://pulse.turbobytes.com/results/560c589decbe400bf8001bbf/ . Tested from multiple points. The tool does TLS validations. Unrelated: That endpoint seems to be blackholed from china... What common name do you see in the cert given to you? I see "a248.e.akamai.net" which is valid. -Sajal On Thu, Oct 1, 2015 at 4:16 AM Jim Witherell via Outages <outages@outages.org> wrote: e noticed SSL warnings based around Akamai's "a248.e.akamai.net" certificate today. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015. Wonder why we are noticing the errors from multiple points on the internet now? Jim Witherell Cincinnati OH _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
Issue is definitely a mismatched CN for me. Looks like Akamai pushed out a CNS cert to some endpoints without having the SANs fully populated for all of their customers sharing the cert.
On Sep 30, 2015, at 4:55 PM, Jim Witherell via Outages <outages@outages.org> wrote:
For instance go to https://www.irs.gov and https://Cincinnati.com and you should see it.
We saw it here in the office, and at a few home employees tried it, and on cell phones from vzw and AT&T to.
Sent from Yahoo Mail on Android <https://overview.mail.yahoo.com/mobile/?.src=Android> From:"Sajal Kayan" <sajal83@gmail.com> Date:Wed, Sep 30, 2015 at 5:52 PM Subject:Re: [outages] Akamai Cert Issues today
Certificate validates for me (on chrome) And also https://pulse.turbobytes.com/results/560c589decbe400bf8001bbf/ <https://pulse.turbobytes.com/results/560c589decbe400bf8001bbf/> . Tested from multiple points. The tool does TLS validations. Unrelated: That endpoint seems to be blackholed from china...
What common name do you see in the cert given to you? I see "a248.e.akamai.net <http://a248.e.akamai.net/>" which is valid.
-Sajal
On Thu, Oct 1, 2015 at 4:16 AM Jim Witherell via Outages <outages@outages.org <javascript:return>> wrote: e noticed SSL warnings based around Akamai's "a248.e.akamai.net <http://a248.e.akamai.net/>" certificate today <>. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015 <>. Wonder why we are noticing the errors from multiple points on the internet now? Jim Witherell
Cincinnati OH
_______________________________________________ Outages mailing list Outages@outages.org <javascript:return> https://puck.nether.net/mailman/listinfo/outages <https://puck.nether.net/mailman/listinfo/outages> _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
On Wed, 30 Sep 2015, Jim Witherell via Outages wrote:
e noticed SSL warnings based around Akamai's "a248.e.akamai.net" certificate today. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015. Wonder why we are noticing the errors from multiple points on the internet now?
This is how Akamai has handled non-SSL customers for the last 15 years. It is the same error message, and the same action. You just noticed it. If you use https for a non-SSL customer on Akamai, you will connect to a Akamai server using a "default" SSL certificate for all customers on port 443. If you use https for a SSL customer on Akamai, you connect to different IP addresses listening for specific customers which return a customer specific SSL certificate.
Nice to know. I noticed this recently on the Vimeo API as well, so it's not just Gov sites. Thank you for taking the time to share the info. Kind regards, Jordan Michaels ----- Original Message ----- From: "Sean Donelan via Outages" <outages@outages.org> To: Outages@outages.org Sent: Wednesday, September 30, 2015 3:29:04 PM Subject: Re: [outages] Akamai Cert Issues today On Wed, 30 Sep 2015, Jim Witherell via Outages wrote:
e noticed SSL warnings based around Akamai's "a248.e.akamai.net" certificate today. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015. Wonder why we are noticing the errors from multiple points on the internet now?
This is how Akamai has handled non-SSL customers for the last 15 years. It is the same error message, and the same action. You just noticed it. If you use https for a non-SSL customer on Akamai, you will connect to a Akamai server using a "default" SSL certificate for all customers on port 443. If you use https for a SSL customer on Akamai, you connect to different IP addresses listening for specific customers which return a customer specific SSL certificate. _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
So what to do as a user of the sites? We're not associated with these sites at all but end users call our help desk blaming us. Both examples are common sites to go to, and today they decide to act up. Thoughts on why today is the day? Sent from Yahoo Mail on Android From:"Jordan Michaels via Outages" <outages@outages.org> Date:Wed, Sep 30, 2015 at 6:59 PM Subject:Re: [outages] Akamai Cert Issues today Nice to know. I noticed this recently on the Vimeo API as well, so it's not just Gov sites. Thank you for taking the time to share the info. Kind regards, Jordan Michaels ----- Original Message ----- From: "Sean Donelan via Outages" <outages@outages.org> To: Outages@outages.org Sent: Wednesday, September 30, 2015 3:29:04 PM Subject: Re: [outages] Akamai Cert Issues today On Wed, 30 Sep 2015, Jim Witherell via Outages wrote:
e noticed SSL warnings based around Akamai's "a248.e.akamai.net" certificate today. NET::ERR_CERT_COMMON_NAME_INVALID is the most common error we're seeing. Can anyone comment on what may be going on? Looks like the cert was renewed or issued on 8/27/2015. Wonder why we are noticing the errors from multiple points on the internet now?
This is how Akamai has handled non-SSL customers for the last 15 years. It is the same error message, and the same action. You just noticed it. If you use https for a non-SSL customer on Akamai, you will connect to a Akamai server using a "default" SSL certificate for all customers on port 443. If you use https for a SSL customer on Akamai, you connect to different IP addresses listening for specific customers which return a customer specific SSL certificate. _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
----- Original Message -----
From: "Sean Donelan via Outages" <outages@outages.org>
This is how Akamai has handled non-SSL customers for the last 15 years. It is the same error message, and the same action. You just noticed it.
If you use https for a non-SSL customer on Akamai, you will connect to a Akamai server using a "default" SSL certificate for all customers on port 443.
If you use https for a SSL customer on Akamai, you connect to different IP addresses listening for specific customers which return a customer specific SSL certificate.
Doesn't that interact rather badly with HTTPS-Anywhere? Or, more to the point, would it not already have done so to date, rather loudly? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Aside from finding ways to make it fail, my point is that casual users are complaining to the help desk about it. We can duplicate it externally at home and on mobile devices. Away from the debate about Akamai's issue that has evidently been out there awhile: -We're wondering what happened yesterday to break all these disparate websites -We're wondering if anyone else is seeing the problem or are receiving unusually high volume of complaints about getting to certaincertain and unrelated https sites in the last 18 or so hours. Sent from Yahoo Mail on Android From:"Jay Ashworth via Outages" <outages@outages.org> Date:Wed, Sep 30, 2015 at 11:21 PM Subject:Re: [outages] Akamai Cert Issues today ----- Original Message -----
From: "Sean Donelan via Outages" <outages@outages.org>
This is how Akamai has handled non-SSL customers for the last 15 years. It is the same error message, and the same action. You just noticed it.
If you use https for a non-SSL customer on Akamai, you will connect to a Akamai server using a "default" SSL certificate for all customers on port 443.
If you use https for a SSL customer on Akamai, you connect to different IP addresses listening for specific customers which return a customer specific SSL certificate.
Doesn't that interact rather badly with HTTPS-Anywhere? Or, more to the point, would it not already have done so to date, rather loudly? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 _______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
On 2015-10-01 08:09, Jim Witherell via Outages wrote:
Away from the debate about Akamai's issue that has evidently been out there awhile:
-We're wondering what happened yesterday to break all these disparate websites
-We're wondering if anyone else is seeing the problem or are receiving unusually high volume of complaints about getting to certaincertain and unrelated https sites in the last 18 or so hours.
note that this is *by design*, as sean pointed out. the "fix" is simple: don't use https on www.irs.gov. any ssl pages served by the irs as served on different hostnames. as to why your users just started it, nfi. my best guess is that they weren't using https previously. -- coolhandluke
I'm not certain it's related, but we began noticing anomalies a couple days ago on most Microsoft websites (Microsoft.com, MSDN, Technet, etc.) when trying to view them through our Sophos web security (proxy) appliance. Many elements fail to load causing the sites to look like garbage. When I try to download one of these elements from the Sophos appliance itself, I see the following certificate error: WARNING: cannot verify i-msdn.sec.s-msft.com's certificate, issued by `/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA1': Unable to locally verify the issuer's authority. I can't reproduce this error when loading the sites directly. Only through the Sophos appliance. Christopher Thompson IT INFRASTRUCTURE MANAGER (952)906-7491 westwoodps.com From: Outages [mailto:outages-bounces@outages.org] On Behalf Of Jim Witherell via Outages Sent: Thursday, October 1, 2015 7:10 AM To: outages@outages.org Subject: Re: [outages] Akamai Cert Issues today Aside from finding ways to make it fail, my point is that casual users are complaining to the help desk about it. We can duplicate it externally at home and on mobile devices. Away from the debate about Akamai's issue that has evidently been out there awhile: -We're wondering what happened yesterday to break all these disparate websites -We're wondering if anyone else is seeing the problem or are receiving unusually high volume of complaints about getting to certaincertain and unrelated https sites in the last 18 or so hours. Sent from Yahoo Mail on Android<https://overview.mail.yahoo.com/mobile/?.src=Android> ________________________________ From:"Jay Ashworth via Outages" <outages@outages.org<mailto:outages@outages.org>> Date:Wed, Sep 30, 2015 at 11:21 PM Subject:Re: [outages] Akamai Cert Issues today ----- Original Message -----
From: "Sean Donelan via Outages" <outages@outages.org<javascript:return>>
This is how Akamai has handled non-SSL customers for the last 15 years. It is the same error message, and the same action. You just noticed it.
If you use https for a non-SSL customer on Akamai, you will connect to a Akamai server using a "default" SSL certificate for all customers on port 443.
If you use https for a SSL customer on Akamai, you connect to different IP addresses listening for specific customers which return a customer specific SSL certificate.
Doesn't that interact rather badly with HTTPS-Anywhere? Or, more to the point, would it not already have done so to date, rather loudly? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com<javascript:return> Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info <http://www.bcp38.info%20> 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 _______________________________________________ Outages mailing list Outages@outages.org<javascript:return> https://puck.nether.net/mailman/listinfo/outages Confidentiality Statement: This message and any attachments may contain confidential, proprietary or legally privileged information. Any unauthorized dissemination, use, or disclosure of this information, either in whole or in part, is strictly prohibited. The contents of this e-mail are for the intended recipient and are not meant to be relied upon by anyone else. If you have received this message in error, please advise the sender by reply e-mail, and delete this message and any attachments. Thank you.
On 10/2/15 1:31 PM, Christopher Thompson via Outages wrote:
I’m not certain it’s related, but we began noticing anomalies a couple days ago on most Microsoft websites (Microsoft.com, MSDN, Technet, etc.) when trying to view them through our Sophos web security (proxy) appliance. Many elements fail to load causing the sites to look like garbage. When I try to download one of these elements from the Sophos appliance itself, I see the following certificate error:
WARNING: cannot verify i-msdn.sec.s-msft.com's certificate, issued by `/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA1':
Unable to locally verify the issuer's authority.
I can’t reproduce this error when loading the sites directly. Only through the Sophos appliance.
Your appliance can't validate an intermediate ca which the browsers keyring apparently can.
Christopher Thompson IT INFRASTRUCTURE MANAGER (952)906-7491 westwoodps.com
*From:*Outages [mailto:outages-bounces@outages.org] *On Behalf Of *Jim Witherell via Outages *Sent:* Thursday, October 1, 2015 7:10 AM *To:* outages@outages.org *Subject:* Re: [outages] Akamai Cert Issues today
Aside from finding ways to make it fail, my point is that casual users are complaining to the help desk about it. We can duplicate it externally at home and on mobile devices.
Away from the debate about Akamai's issue that has evidently been out there awhile:
-We're wondering what happened yesterday to break all these disparate websites
-We're wondering if anyone else is seeing the problem or are receiving unusually high volume of complaints about getting to certaincertain and unrelated https sites in the last 18 or so hours.
Sent from Yahoo Mail on Android <https://overview.mail.yahoo.com/mobile/?.src=Android>
------------------------------------------------------------------------
*From*:"Jay Ashworth via Outages" <outages@outages.org <mailto:outages@outages.org>> *Date*:Wed, Sep 30, 2015 at 11:21 PM *Subject*:Re: [outages] Akamai Cert Issues today
----- Original Message -----
From: "Sean Donelan via Outages" <outages@outages.org <javascript:return>>
This is how Akamai has handled non-SSL customers for the last 15 years. It is the same error message, and the same action. You just noticed it.
If you use https for a non-SSL customer on Akamai, you will connect to a Akamai server using a "default" SSL certificate for all customers on port 443.
If you use https for a SSL customer on Akamai, you connect to different IP addresses listening for specific customers which return a customer specific SSL certificate.
Doesn't that interact rather badly with HTTPS-Anywhere?
Or, more to the point, would it not already have done so to date, rather loudly?
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com <javascript:return> Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info <http://www.bcp38.info%20> 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
_______________________________________________ Outages mailing list Outages@outages.org <javascript:return> https://puck.nether.net/mailman/listinfo/outages
*Confidentiality Statement: *
This message and any attachments may contain confidential, proprietary or legally privileged information. Any unauthorized dissemination, use, or disclosure of this information, either in whole or in part, is strictly prohibited. The contents of this e-mail are for the intended recipient and are not meant to be relied upon by anyone else. If you have received this message in error, please advise the sender by reply e-mail, and delete this message and any attachments. Thank you.
_______________________________________________ Outages mailing list Outages@outages.org https://puck.nether.net/mailman/listinfo/outages
participants (10)
-
Chris Swingler -
Christopher Thompson -
coolhandluke -
Jay Ashworth -
Jeff Walter -
Jim Witherell -
joel jaeggli -
Jordan Michaels -
Sajal Kayan -
Sean Donelan