This is interesting. When I go to that url in Firefox (linux) I get the page full of the providers - all smashed together. When I go to it in Chrome I get the same cert error I got from Channels when trying to add the source. Here's what I see in Chrome:
My dates are different for the same url. It does however show different cert fingerprints for some reason.
If anything is different in the certificate you see vs. what I see, the fingerprints will be different.
Try changing your DNS Server to quad 1, 8 or 9
What are you currently using for DNS Servers?
Are they different between your Ubuntu and Windows PC's?
You can check to see what a certificate fingerprint SHOULD BE at the Steve Gibson's website GRC | SSL TLS HTTPS Web Server Certificate Fingerprints
Try https://sp.auth.adobe.com there
I run my own dns server (and dhcp, smtp, etc.) but my forwarder is 1.1.1.1. I edited the resolv.conf in the docker container and pointed it to 8.8.8.8 - no change.
I have numerous linux boxes, 1 physical win11, several vm win boxes, a NAS, a large lab, and a bunch of iOT stuff. All pull from a little nuc that runs the dns/dhcp/mail/vpn/rsyslog. All boxes use that box for nearly everything other than my NAS services.
I think choosing the Optimum source grabs a different cert somewhere in a tree for that provider, but named the same.
Here is what I see when I go with Firefox to https://sp.auth.adobe.com/adobe-services/config/ABC?noflash=true
Here is what I see on Chrome - same url (both after changing docker dns to 8.8.8.8
Maybe chrome and firefox do something different, but The firefox screenshot may heelp show what I am talking about with the providers mashed together.
That's just the XML file the website is supposed to return when you go there.
If a browser (your Chrome) can't validate a certificate at a secure website (HTTPS://sp.suth.adobe.com), it will fail to load the website contents (the xml file).
Not sure if this new update is related, but try updating and run Troubleshooting again.
Also try the same website using Chrome and Firefox on Windows if you can.
I'll give that a try in a few. I just noticed something in that XML file.
Optimum has 2 entries everywhere - CDVR, the XML file, and other places. I have Optimum, and the Optimum TV uses a different box or device. My ID only works with Optimum. Having said that, look at the section of the XML that houses Optimum and Optimum TV:
<mvpd>
<id visible="true">Cablevision</id>
<displayName visible="true">Optimum</displayName>
<logoUrl visible="true">https://idpssoopt.alticeusa.com/sso/optimum/images/optimumlogo/logo_loggedin2x.png</logoUrl>
<foregroundLogout>true</foregroundLogout>
<authPerAggregator>false</authPerAggregator>
<iFrameRequired visible="true">false</iFrameRequired>
</mvpd>
<mvpd>
<id visible="true">AlticeOne</id>
<displayName visible="true">Optimum TV</displayName>
<logoUrl visible="true">https://idpssoalt.alticeusa.com/sso/alticeusa/images/alticelogo/logo_picker.png</logoUrl>
<foregroundLogout>true</foregroundLogout>
</mvpd>
Notice the Optimum TV (AlticeOne) entry (from that ABC XML) doesn't have the authPerAggregator line.
I thought that was a little strange.
Your Chrome isn't even seeing that since it sees an expired certificate before it can get that from the website. Besides, you said you're using Optimum, not Optimum TV.
Go here ABC Live Stream - ABC.com in your Chrome browser and log in, Link Provider using Optimum and see if you can stream from the website (that's step 1 in TVE Troubleshooting tips).
Aah.
I tried adding the source again after updating to today's pre-release. Still the same outcome.
What you just said though peaked my interest. When I am trying the " https://sp.auth.adobe.com/adobe-services/config/ABC?noflash=true" url I'm just putting that in the url field, hitting return, and getting a response - there is no authentication like when I try to add a source. Why can I see that with Firefox but not Chrome since both are using the same expired source?
Oh - I was using the xml Altice/Optimum as a comparison and wondering if Optimum maybe should've deleted that line like Altice did. Figured maybe it could be a bug or something.
Reran the troubleshooter and still all green. It noticed my DNS change from 1.1.1.1 to 8.8.8.8 and said this:
DNS
Using public DNS resolver from "Google LLC" can cause problems with TV Everywhere
Cloudflare had the same message. I wonder why both of them say they can cause problems with TVE?
It is green though.
I have tried a bunch of the channels in my browser and can authenticate and watch them all with no issue. The "NBC" test in the troubleshooting guide was my first test.
I'm going to try that in a few when I can get to my windows box in my home office. Wife was using Word on that. Never move the wife.
Using the same Chrome browser that your Channels DVR Server uses?
I think you're running CDVR in a container, so it wouldn't be the same Chrome you use on the desktop.
Right - I can't use the same browser in the container. I've now tried this:
Linux - Chrome, Brave, Firefox, and "web" - which is Chromium
Win11 - Chrome, Firefox
Android - Firefox, Brave
All allow me to view TVE in the browser after linking the provider to Optimum.
None allow me to add the source via the channels UI add source - even in either the same tab I used to watch live tv, or another tab in the same browser while the live tv plays in another tab (still linked).
This is with the standard CDVR build, the pre-release from 2 days ago, and the pre-reelease from today.
Since you said you followed all the troubleshooting steps in TVE Troubleshooting tips
You must have done step 15.
From my email: Web UI Troubleshooting log files - 1fc31a5d-368f-4681-aadd-9d597bbbdd6e (all green checks).
No - same errors. Just tried it again.
2025/07/25 17:31:44.579686 [TVE] Auth starting for Cablevision as dec3169
2025/07/25 17:31:44.715666 action=requestor err=Get "https://sp.auth.adobe.com/adobe-services/config/ABC?noflash=true": tls: failed to verify certificate: x509: certificate has expired or is not yet valid: current time 2025-07-25T17:31:44-05:00 is after 2025-06-15T23:59:59Z
2025/07/25 17:31:44.715741 [TVE] action=auth mvpd=Cablevision requestor=ABC
2025/07/25 17:31:44.963210 [TVE] action=version product=Chrome/132.0.6834.83 jsVersion=13.2.152.27 protocol=1.3 revision=@03d59cf5ecf1d8444838ff9a1e96231304d4ff9c
2025/07/25 17:31:44.963576 [TVE] action=page_ready chromeVersion=132
2025/07/25 17:31:44.963699 [TVE] action=navigate url=https://sp.auth.adobe.com/adobe-services/authenticate/saml?noflash=true&mso_id=Cablevision&requestor_id=ABC&no_iframe=true&domain_name=adobe.com®_code=&redirect_url=https%3A%2F%2Fsp.auth.adobe.com%2Fadobe-services%2FcompletePassiveAuthentication
2025/07/25 17:31:44.964797 [TVE] action=request type=Document method=GET url=https://sp.auth.adobe.com/adobe-services/authenticate/saml
2025/07/25 17:31:45.228010 [TVE] action=error_response type=Document error=net::ERR_CERT_DATE_INVALID url=https://sp.auth.adobe.com/adobe-services/authenticate/saml ip=54.68.29.35
2025/07/25 17:31:45.302022 [TVE] action=wait_for_page
2025/07/25 17:31:50.350233 [TVE] action=page_ready
2025/07/25 17:31:50.350269 [TVE] action=wait_for_page done=true reason=page_ready
2025/07/25 17:31:50.350283 [TVE] action=wait_for_auth timeout=12s
2025/07/25 17:31:50.350298 [TVE] action=fill_form u=dec3169
2025/07/25 17:31:50.353319 [TVE] action=fill_form state=done err=&runtime.ExceptionDetails{ExceptionID:1, Text:"Uncaught (in promise)", LineNumber:0, ColumnNumber:0, ScriptID:"", URL:"", StackTrace:(*runtime.StackTrace)(nil), Exception:(*runtime.RemoteObject)(0xc0007f1050), ExecutionContextID:0, ExceptionMetaData:easyjson.RawMessage(nil)}
2025/07/25 17:31:50.353356 [TVE] action=screenshot
2025/07/25 17:31:50.370770 [TVE] action=screenshot file=tve_error_screenshot.png size=37264
2025/07/25 17:31:50.370870 [TVE] action=capture_html
2025/07/25 17:31:50.372739 [TVE] action=capture_html file=tve_error_screenshot.html size=149170
2025/07/25 17:31:50.372868 [TVE] action=capture_html
2025/07/25 17:31:50.374530 [TVE] action=capture_html file=tve_error_screenshot.html size=149170
2025/07/25 17:31:50.379573 [TVE] action=script_error err=no login form found
2025/07/25 17:31:50.459147 [TVE] Auth failed for Cablevision: no login form found
Reminder - while I'm doing all this I am watching a channel from my 2nd source using KlowdTV. In case that matters - it is working fine.
Seems like a bad dns cache somewhere in your stack.
You could compare i.e dig <hostname>
Which host should I dig - sp.auth.adobe.com? I tried that last night and it looked ok.
I will say I looked at my dns last night and I don't have caching turned on (couldn't remember because I've run it so long). I changed the dns serial number, did an upgrade on Ubuntu just in case, and even updated to today's pre-release - and rebooted. Still the same results and the same errors in the log.
I checked my syslogs on the host running CDVR (and dns secondary) and had one time in June where all my dns forwarders (like 8.8.8.8, 1.1.1.1, and 4.2.2.1) timed out trying to reach channels-dvr.s3.amazonaws.com but that was during a brief cable internet outage. That's expected.
I made sure to turn my vpn proxy (in another docker container) off and verified my IP with whatsmyip.org to ensure it was my ISP and not somewhere else. I disabled adblocker in the settings - not just for the page I was on. I can't think of anything I missed.
Could it be an issue with Optimum? Maybe their cert really is expired and they didn't notice because most people using TVE are using it on the web (especially probably in my area). I want to know because I've been looking at other TV providers that will work with CDVR and are cheaper than Optimum's cable. I'd hate to switch and have them not work as well. I have to keep Optimum's Internet though - it is the only 1gb in my area until the fiber company hits my area.
I can always send more logs if you need me to. I am running CDVR 2025.07.26.0227 in docker on Ubuntu 24.04.2 with 128GB RAM, a decent GPU, 12th Gen Intel(R) Core(TM) i9-12900K with 24 cores, and 21TB free disk space. The system is on ethernet directly connected to my 6E mesh wifi router master, then to the cable modem (personal, and provisioned by Optimum - not the Optimum trash that never gave me over 700mbps). Speedtest just gave me 939.28mbps down and 53mbps up (they only do 50mbps up). I know system resources aren't an issue.
Thank you for looking at this. Judging by your profile I don't think there is anyone better than you to help. I really appreciate it.
If you view the certificate for the server Channels DVR is hitting, you'll see it's expired.
https://54.68.29.35/
You need to get DNS to resolve the hostname to a different server IP address.
Try ping sp.auth.adobe.com to see what IP that hostname resolves to
From my Windows PC
ping -4 -n 1 sp.auth.adobe.com
Pinging ethos501-prod-or2-k8s-p2-0-a1ad666b2de4356f.elb.us-west-2.amazonaws.com [44.229.68.88] with 32 bytes of data:
From inside my Channels DVR container on my NAS
# ping -4 -c1 sp.auth.adobe.com
PING sp.auth.adobe.com (44.225.76.132): 56 data bytes
Those servers certificates are not expired.
Using my Windows PC
Network Inspector in EDGE shows
Request URL https://sp.auth.adobe.com/
Request Method GET
Status Code 200 OK
Remote Address 44.229.68.88:443
Referrer Policy strict-origin-when-cross-origin
Network Inspector in BRAVE shows
Request URL https://sp.auth.adobe.com/
Request Method GET
Status Code 200 OK
Remote Address 44.225.76.132:443
Referrer Policy strict-origin-when-cross-origin
Network Inspector in FIREFOX shows
method GET
scheme https
host sp.auth.adobe.com
filename /
Address 44.225.76.132:443
Status 304
Version HTTP/2
Transferred 1.14 kB (26 B size)
DNS Resolution System
This is the solution thanks to chDVRuser and tmm1. They both got me looking into name resolution and I found the modified /etc/hosts file in the container thanks to them. Solution was to remove the hardcoded entries for the host sp.auth..adobe.com.
So between chDVRuser and tmm1 I was able to get enough clues to fix this. Apparently some time in the past I must've edited the /etc/hosts file in the container - unless something does that automatically? I don't recall ever getting into the container to do that, but the file looked like this:
127.0.0.1 localhost
127.0.1.1 cartman
#198.54.122.135 mail.privateemail.com
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
# Added by Docker Desktop
# To allow the same kube context to work on the host and the container:
127.0.0.1 kubernetes.docker.internal
# End of section
#
54.68.29.35 sp.auth.adobe.com
44.239.120.244 sp.auth.adobe.com
Note the sp.auth.adobe.com entries at the bottom. The one that starts with 54 was the expired one.
I deleted those 2 lines, saved it, and exited the container. Then I successfully added the source and got 140 channels. I bet when the one cert expired I started losing channels, but is it common for providers to use 2 separate IPs and certs for their TVE range? Seems odd, but possible I guess.
I don't know who to mark for the solution since you both helped me. Aman, if you want to mark one of the posts as a solution that's fine. I appreciate the help, and now I know more than I thought I wanted to about the internals of CDVR 
Thanks!
BTW - sorry for any typos. My laptop is 11 years old and keys are starting to stick or not work. Guess I have to remove 5000 screws and clean the keyboard.
Adobe maintains many servers around the world and most likely uses load balancing and your DNS Server will choose the closest available server. So you will see the IP address for the host changing all the time. Same with any large company, like Google for instance. That's why trying to maintain a hosts file "is so 1970's".