I am struggling with generating LetsEncrypt SAN SSL for SBS 2011 for few days. All is going fine, until ACME CHALLENGE verification.
I cannot use DNS verification, because DNS is at ISP and it takes days for any change to get live. So only HTTP validation can be used.
Where IIS stucks?
Simply when it tries to server extension-less ACME VALIDATION file, IIS returns 404 ERROR. File is there, Acme client generates it just fine in proper folder, but it does not show up via web browser, just 404 error due to MIME type. When testing with test.html file in same folder it gets displayed properly, no problem.
I've already tried:
Adding MIME type text/plain for "." and ".*" extensions, but no go
Moved StaticFile mappings above ExtensionLessUrlHandlers, but still no go
Edited applicationhost.config file and set to Allow: <section name="handlers" overrideModeDefault="Allow" />
Restarted IIS and whole server, still at no avail
Used different LE clients, but all of them use IIS and stuck at the same point
Solution from here does NOT work: IIS: How to serve a file without extension?
When I try localy, I always get this 404 Error in browser:
HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
Module IIS Web Core
Notification MapRequestHandler
Handler StaticFile
Error Code 0x80070002
Any more idea?
Sorry, folks! It was my bad, not being carefull enough when passing details to you.
The solution to add "." as MIME Type "text/plain" is the only thing needed in my OP case.
What was wrong in my case was the "autodiscover" sub-domain, which I still do not know, where it's being served from, but definitelly it is NOT from "Autodiscover" application under Default Web Site. As of now, when I browse "autodiscover.domain.com..." link I still get cached test.html content, but I've deleted all test.html files which I planted there.
Ok, but, that's not the subject here.
BTW...LE test failed on my Firewall on Country Blocking rules. Oh, my...
Thank you for participation.
Related
Hard to explain in the subject what's my problem, but it will have sense I promise.
I debug locally with an URL different than localhost (due to azure AD redirect), I have all the HOST configurations in place, everything works fine except for this "Not Secure" warning, that sometimes annoys my UI while calling the BE.
But if I navigate my page by using LOCALHOST:same port, the issue is not present.
What steps should I configure in order to prevent this warning while using an URL? So it works similar to LOCALHOST.
I tried so far to include the certificate in the Personal folder (following several tutorials) but did nothing.
Regards.
I have a client who I am trying to setup an SSL certificate for via SSL for Free, like I have done 100 times before.
I created the file structure under public_html:
.well-known > pki-validation > <uploaded verification file>
I then tried to download the certificate and got the following failure message:
Warning: Your verification URL is not returning the correct contents
to our verification servers. The URL looks like it is blocking bots
and which inadvertently blocks our servers from receiving the correct
content. Contact your host, a professional developer or admin for
further help with fixing it.
I assumed this was due to the robots.txt file, had a look and it included the following:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
So I changed it to temporarily allow all bots using:
User-agent: *
Disallow:
I then retried the process, uploading the new verification file, but still, I get the same warning message about the URL blocking the bots. Has anyone come across this before and know how to fix it?
I've also tried verification via a DNS .txt record and via FTP, both returning the same failure notices.
Hosting is through GoDaddy and they're using Linux cPanel. The website is made through WordPress.
Typing in example.com/robots.txt returns the correct robots.txt file.
Thank you for all and any help!
I've now fixed this issue. It was indeed to do with the robots.txt file as I had initially thought. The reason it didn't initially work is the site was still cached with the old file, which was blocking bots throughout the site.
I added some code to my .htaccess file to force re-validation of the cache:
ExpiresActive On
ExpiresDefault A1
Header append Cache-Control must-revalidate
After doing this and with my new robots.txt file, I was able to install the new SSL certificate to the website which is now working! I hope this helps anyone having the same issue.
Just remember to remove the above code afterwards, as it will temporarily stop your site from caching.
I resolved this issue within the SSL For Free portal. After clicking on renew within the "certificates" link, I hit the "regenerate account" link. Then went through the usual steps to renew and it worked.
I have currently 3 web server configuration with HAProxy dividing the traffic to one of each web server. Each server is running apache2 with mod_pagespeed. The HAProxy takes care of the SSL termination as the web servers are in local network.
HAProxy sets the X-Forwareded-Proto header to each request and I have enabled "ModPagespeedRespectXForwardedProto on" in each pagespeed configuration.
Apache services are running in custom port 8012 and now I am getting an error to javascript console from pagespeed when going to the site:
Mixed Content: The page at 'https://www.example.com/' was loaded over HTTPS, but requested an insecure script 'http://www.example.com:8012/_,Mjo.NZsywmsdso.js.pagespeed.jm.OLNkjPSHpv.js'. This request has been blocked; the content must be served over HTTPS.
Any idea what could still be wrong? Here is the pagespeed HTTPS configuration:
ModPagespeedFetchFromModSpdy on
ModPagespeedFetchHttps enable
ModPagespeedSslCertDirectory /etc/ssl/certs
ModPagespeedSslCertFile /etc/ssl/certs/cert.pem
ModPagespeedMapOriginDomain "http://www.example.com" "https://www.example.com"
ModPagespeedRespectXForwardedProto on
Any help is appreciated!
This question is old, but I am going to answer how I fix it on my own setup.
The issue comes if you are using pagespeed on each server vs somehow running it on haproxy itself for caching. Since pagespeed saves a copy of any modified file with a modification on filename, then it also changes the source of the HTML to match that new filename it stored, which should work fine. But the issue is that is pagespeed on web server 1 is modifying the HTML to match background compressing of the files(images, js, css, etc) then when it gets to the users computer and their browser requests such files it wont find it if you are round-robin it between servers because that file will be only on web server 1 and not on the others, the way around it is to use a shared folder for the pagespeed so when one compresses a file into that folder, the other web servers will see it through their pagespeed.
I have a little strange issue on my system. I have hosted a Service, Rest Service (Be Specific) on my system. When I try to access the svc page of the same service it gives me HTTP 404 (The resource cannot be found.) error while I can browse the whole directory and in that directory it shows that the svc file lies with in the folder but when I click on svc file i get the 404 error.
I tried to host the same service on other system and it works fine. I am not sure what causing it not to display on my system.
Any clue would be great help.
I am trying to publish via something more reliable than the FTP option, which works very intermittently from visual studio - and is very slow. So let me first ask you: In 2011, using visual studio to publish, is WebDAV the best option?
Anyway, I've got WebDAV hosted by IIS 7 up and running, and I have managed to map it as a drive. I can copy files there aswell, except anything with the file extension .svc. I can publish everything else I've tried, and also publish the .svc file if I first rename it to something else, then renaming back after it already is in the WebDAV directory.
Here is the IIS log:
2011-03-19 18:32:54 192.168.0.9 PROPFIND /bin/service.svc - 80 SERVER\User my.ip.not.shown Microsoft-WebDAV-MiniRedir/6.1.7600 405 0 0 0
As you can see, it ends in 405.
The only similar thing I've managed to google up could be solved by configuring the , and sections of the applicationHost file. The logical thing would be to check for an entry in , but it says nothing about .svc. I've also tried setting applyToWebDAV to false.
Any ideas?
UPDATE:
Thinking on it, could it simply be that the WCF http handler intercepts the url, since .svc is registered with that handler?
Alright, I figured it out. The WCF handler was ordered before the WebDAV handler in the handler mappings, so it intercepted requests to *.svc. It in turn returned 405 method not allowed for PROPFIND.
Simply move the WebDAV entry upwards in the list until it is listed appropriately early in the mappings.