Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Access Denied. You don't have permission to access "http://selfsolve.apple.com/agreementWarrantyDynamic.do" on this server

Web page shown " Access Denied. You don't have permission to access "http://selfsolve.apple.com/agreementWarrantyDynamic.do" on this server" when browse URL: http://selfsolve.apple.com/agreementWarrantyDynamic.do

Posted on Jun 29, 2015 9:37 PM

Reply
25 replies

Jul 7, 2015 9:05 AM in response to Dawnaw

Dawnaw wrote:


  1. Thank you for taking the time to reply. Glad to know that someone has possibly fixed THEIR issue, but ours persists.
  2. Apple Support was less than supportive, telling me that our server is blocking this site. Our IT guy says we don't have that ability.
  3. Any ideas to whom do we address this issue? Our Apple rep has not replied after sending three requests.


Any assistance is appreciated!!!

  1. You're welcome. Since the issue "persists", you must continue to be "persistent".
  2. Apple support is likely right = sort of = if there is a blockage, SOME server(service) is doing it. If your IT guy is not the culprit as you say, he also should understand that there are layers between your network and Apple's that have that capability
  3. Apple is not responsible, so waiting for your Apple rep is fruitless.
    1. Start with your IT guy tracing the "TRACEROUTE" chain
    2. The first "hop" from your network is to your company's Internet Service Provider (ISP) - they are the only folks that would even take an interest in such matters... to wit:


ISPs have been know to block stuff. For example I will use a scenario from a company where I used to work as a tech support supervisor:


We had an application that had a "magic twanger" functionality that used email to send data files from our users to us and to their recipient of choice. I will simplify as best I can:

  • If our client was a Time Warner Cable "ISP" customer
    AND
  • their recipient's WebHost/eMail service had a SPAMmer as a customer that TWC had identified
  • TWC would BLOCK ALL IP addresses to that WebHost - rather than just the IP address of the SPAMmer (TWCs logic was that if the WebHost would not police their customers, TWC would teach them all a lesson)
  • This was done 'blindly' so that the "people" involved never communicated - i.e., TWC never 'notified' the WebHost, they just 'flipped the switch'


I cannot imagine why your company's ISP would be blocking services from Apple (it seems that the key word here is "services" - since it is only the ultra-secure "selfsolve" subdomain affected)


Action Plan is for your IT guy to call the IT guy at your ISP and let them work out a plan for solving this - an ISP may have best chance of communicating with Apple IT folks


This thread would benefit from progress reports - the previous folks that simply dropped out of the conversation may have had concrete solution, if they only had said so.


Let me add to my "story" - when I, TWC and the WebHost communicated about the issue, it was fixed in a matter of moments.

Jul 7, 2015 11:16 AM in response to Dawnaw

Dawnaw wrote:


Thanks for all the pointers!!!


Our IT guy is looking into it, and our Apple rep send this thread up the ladder also.

You're welcome. And thanx for the update!! My $$ is on your ISP - solving your issue may solve the same one for thousands if it is a "popular" provider😎


My traceroute looks very much less complicated (# of hops) than I would have guessed - possibly because of the distributed nature of Apple/AkemaiTechnologies server deployment - most hops are within the TWC 'system' (my ISP) ".....rr.com".::. " rr " stands for RoadRunner, TWC's 'network'


From Mac OS X "Network Utility.app" [Traceroute] - note that MY IP address is merely a standard IP assignation by my wireless router's VPN


traceroute to selfsolve.apple.com.edgekey.net (172.233.78.196), 64 hops max, 40 byte packets

  1. 1 192.168.0.1 (192.168.0.1) 2.055 ms 0.447 ms 0.238 ms
  2. 2 cpe-72-190-92-1.tx.res.rr.com (72.190.92.1) 18.012 ms 8.833 ms 17.063 ms
  3. 3 xe0-0-0.dllxtx5001h.texas.rr.com (24.28.88.49) 44.048 ms 44.805 ms 46.573 ms
  4. 4 agg35.crtntxjt01r.texas.rr.com (24.175.49.215) 17.551 ms 15.363 ms 31.195 ms
  5. 5 agg21.dllatxl301r.texas.rr.com (24.175.49.0) 50.721 ms 39.960 ms 9.714 ms
  6. 6 bu-ether14.dllstx976iw-bcr00.tbone.rr.com (66.109.6.88) 43.479 ms 47.613 ms 15.522 ms
  7. 7 0.ae2.pr1.dfw10.tbone.rr.com (107.14.17.236) 19.524 ms 0.ae4.pr1.dfw10.tbone.rr.com (107.14.19.97) 11.441 ms 0.ae2.pr1.dfw10.tbone.rr.com (107.14.17.236) 31.293 ms
  8. 8 107.14.16.210 (107.14.16.210) 21.003 ms 37.026 ms 11.318 ms
  9. 9 a172-233-78-196.deploy.static.akamaitechnologies.com (172.233.78.196) 25.879 ms 13.147 ms 34.540 ms

Jul 7, 2015 11:29 AM in response to dcf_oc

dcf_oc


I skipped the very important point that your made - PROVING that the issue is with your ISP "At home"

SNIP ... I am on a PC and using any browser or any other device through that router is blocked -- however at access points outside of the house I can connect to those sites. In both places, it is regardless of what apple ID is used.

SNIP

Not your devices or software + not Apple either - only variable is what is "in between"


Since you are a "consumer" level user, you need to do the same thing as Dawnaw's IT guy - contact your ISP's SENIOR Tech Specialist and explain your issue. Your "ace in the hole" is your proven success with "access points outside of the house I can connect to those sites"


Keep us informed on YOUR progress as well.


luck

ÇÇÇ

Jul 7, 2015 11:42 AM in response to Percy Ng 1027

To all still having the issue:

View from 30,000 feet?

It is worth noting that any function within the " selfsolve.apple.com " subdomain is very likely being treated, security-wise, as if it were a transaction in the banking system = VERY tip-top protocols. This kind of stuff traveling through an ISP from a NON-bank WebHost (?Apple/AkamaiTechnologies?) might well set off alarm bells in this day in age.


EDITadded - my fumble fingers accidentally deleted this ¶


selfsolve (and other services) must by definition connect to databases that Apple must deem as ULTRA-private and/or Trade Secret level info.

Jul 8, 2015 11:44 AM in response to Percy Ng 1027

*** SOLUTION FOUND ***

*** SOLUTION FOUND ***

*** SOLUTION FOUND ***



After 40 minutes on the phone with Apple and being bumped up the chain to higher and higher seniority techs their end determination was that there is nothing on Apple's side that is the cause. They confirmed they are NOT blocking any IP addresses and that the issue is somewhere on our network or with our ISP.


I have Verizon FIOS at the my office and Time Warner Cable at my home. I was unable to access the site from EITHER location even though they are two completely different ISPs. I called them both and advised them of the issue. After connecting a laptop directly to the router and allowing them remote access they confirmed there is nothing on my local network that is causing the issue.


The solution was simply to have them give me a new Public IP address and restart the router. Once that was done the page loaded without any issue. They could not shed any light on why the original IP address wasn't working with the page. Don't waste time troubleshooting your own network or computer as it apparently as NOTHING to do with your local network. There is something at the ISP level that is the cause; just call your ISP can request a new IP - that worked for us.


- Adam

Nov 18, 2015 6:09 PM in response to Percy Ng 1027

SOLUTION: I experienced this issue after I checked 15 or 20 serial numbers in a short period of time (for our corporate devices.) I was blocked for weeks. I could not even access the http://checkcoverage.apple.com site either. I had to call Apple support, and they confirmed that there is some blacklisting going on. If you have an enterprise or business relationship with Apple, call your Apple Enterprise Support number (otherwise just call the main Apple number.)


My exact error message was:

Access Denied

You don't have permission to access "http://selfsolve.apple.com/" on this server.

Reference #18.72c357b8.1447898710.198e76ad

Access Denied. You don't have permission to access "http://selfsolve.apple.com/agreementWarrantyDynamic.do" on this server

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.