This is what appears many times in console of Jetty local webserver when testing J2EE Spring app.
2012-05-03 14:28:14,716 WARN [org.springframework.web.servlet.PageNotFound]
- <No mapping found for HTTP request with URI [/crls/secureca.crl]
in DispatcherServlet with name 'DefaultServlet'>
I've setup my localhost (OSX) like this:
sudo ipfw add 100 fwd 127.0.0.1,8080 tcp from any to any 80 in
To forward all requests to localhost/127.0.0.1 from :80 to :8080
Does anybody know if this is severe bug/warning and how to get rid of it ?
My mistake, I got (and only god knows why) in /private/etc/hosts
127.0.0.1 crl.verisign.com
127.0.0.1 crl.geotrust.com
So if anybody encounters the same issue, simply check your hosts file for crl, verisign, geotrust keywords and disable or delete matching lines.
Note that commenting in hosts file works like this
#127.0.0.1 crl.geotrust.com
Related
I've seen a lot of similar questions but none of the answers helped me (and there's one addition I didn't see anywhere).
So, I'm using Mamp-Pro 6.0.1 for local testing. I have a domain set up (www.mydomain.lo), enabled SSL and used a self signed certificate I created with the button in Mamp.
I added the cert to my keychain (I'm on a Mac) and set it to «always trust» in the keychain-info.
But when I try to access the local page with https://www.mydomain.lo, I get an error saying:
There was an error connecting to … SSL received an entry which exceeds the max allowed length. Error-Code: SSL_ERROR_RX_RECORD_TOO_LONG
(this is loosely translated from German).
The page works with http:// but I'd like to test the SSL-Version, too.
Any ideas?
I was able to partly solve this riddle.
SSL just doesn't work on local hosts, when the standard port (443) is used.
But it works when the «default MAMP ports» are used.
in MAMP-Pro got to «Ports & User» and click on «Set default MAMP ports».
The ports change as following:
Apache 8888 - SSL 8890
Nginx 7888 - SSL 7890
MySQL 8889
…
It is important that you don't change any of these. I tried to only change the Apache SSL port to 8890 and leave the other ports on their standard (Apache 80, MySQL 3306,…) but then the MySQL-Server doesn't respond.
Solution: It turns out ipv6 has got it's own firewall which I didn't know and it filtered out 80 and 443! Thanks so much Nicholas Pipitone!
I'm having difficulties to get apache to accept ipv6 connections (everything perfect on ipv4). Results from ready.chair6.net:
What I tested/tried:
Disabling firewall doesn't change the result
Getting apache to listen on all interfaces or specifically the ipv6 interface doesnt change the result
Executing 'curl https://v6.ident.me/' correctly sends me back my ipv6 address
Netstat tells me that both the ipv4 AND ipv6 address are listening for connections on 80 and 443
I'm really stuck here, what else can I do?
The MX record error means it's having a problem getting the IP address from the DNS servers.
Solution: Try dig +short AAAA $hostname and dig +short MX $hostname, with $hostname being your URL. If you don't see an IPv6 IP in the terminal, then you don't have DNS fully setup. If you just recently setup your URL, then wait a day for caches to be updated. If it's been a while, talk to who you bought the domain name from / who's responsible for making your URL point to your IP.
Note: MX is only for mail. If you don't want incoming mail / that's not what the problem is, then that test is testing something it doesn't have to test, and you can ignore it.
More possibilities: Is the hostname on line 4 the same as the host name on the second to last line? Try pinging that IPv6 address from line 4 on a different computer (Not on the same private network); what do you get?
If you get a response, try nmaping the IPv6 on another computer to see if port 80 is open to the public.
-If the nmap fails then try checking your port forwarding settings if you're behind a NAT. If you're not behind the NAT then something might be blocking the request in-between their computer and your computer (Very unlikely); you can try telnet'ing to port 80 remotely and see if you're getting the requests - because then it's just an apache issue.
-If nmap succeeded, then what do you get? Send an HTTP request over command line from the another computer and see if you get a response.
If pinging doesn't work, then you're just not connected to the internet (o.O), idk how to help with that. If pinging the IPv6 works but pinging the URL doesn't, then dig must not be showing anything and it's the DNS as mentioned previously. If dig does show something in that case, then I'm lost.
I have drill on a vm and was successfully able to connect to it. I restarted the vm after a power outage and now when I try to start drill in embedded mode - I get the following message
Error: Failure in starting embedded Drillbit: java.net.UnknownHostException: xxxx.localdomain: xxxx.localdomain: Name or service not known (state=,code=0)
Is there a dependency that I need to restart?
Please verify /etc/hosts has entry for that domain with the inet ip. Hope this resolve your problem.
Please add an entry to /etc/hosts like "127.0.0.1 yourhostname" which will solve this problem
Also works adding in /etc/hosts something like:
# keeping in mind that 192.168.0.10 is the ip of your server
127.0.0.1 localhost
192.168.0.10 your-server-01
I'm using Vagrant with apache2 and specifically the command
vagrant share --https 443
It all starts fine and provides a URL. When I access that URL I'm presented with a 400 error:
Bad Request
Your browser sent a request that this server could not understand.
Apache/2.4.12 (Ubuntu) Server at *.vagrantshare.com Port 443
I have been accessing the vagrant machine using https just fine, but it doesn't seem to like to work with vagrant share.
This is a known Vagrant Share bug: https://github.com/webdevops/vagrant-docker-vm/issues/51
The only workarounds I've seen discussed are to use a custom domain or to use another product entirely (e.g. ngrok) to create the share. See the bug discussion here: https://github.com/mitchellh/vagrant/issues/5493#issuecomment-159792794
Vagrant Share docs for custom domains are here: https://atlas.hashicorp.com/help/vagrant/shares/custom-domains
I am trying to set up an apache web server on my vm and im running into some issues. When I do an 'nslookup' on the hostname of the machine this is what I get:
nslookup rhel64.xxxxx.xxxxx.com
Server: xxx.xxx.32.1
Address: xxx.xxx.32.1#53
** server can't find rhel64.xxxxx.xxxxx.com: NXDOMAIN
I'm sure this is a common problem but I'm not sure how to fix it. It seems that dnsmasq can't resolve the hostname. Adding the hostname to /etc/hosts doesn't fix it.
Running on an RHEL6.4 machine.
Thanks in advance.
You should use a DNS server that is able to resolve the name; the one you are using now, at xxx.xxx.32.1,
isn't.
Adding the hostname to /etc/hosts doesn't fix it.
This is because nslookup does a DNS lookup always, it does not read the hosts file. Try using getent instead, for example I get:
$ getent hosts rhel64.xxxxx.xxxxx.com
176.74.176.178 rhel64.xxxxx.xxxxx.com
(By the way, you should use example.com as an example almost always, so you don't inadvertently link to adult-only websites)