Reboot your Linode? Also pastebin your full apache configs and the domain name in question.

Also apache2ctl -S

• Les

Thanks for your reply.

I just tried rebooting, but that didn't help. The situation is still the same.

1. I can reach http://myhost.mydomain.com and see my index.html so I know the Apache server is running.

2. I can't reach https://myhost.mydomain.com, even to get a warning about it not being a trusted certificate. (This is not my goal, because all I want to be able to do is make outgoing secure POST requests to LinkedIn, but is indicative of the problem).

3. And https://www.poodlescan.com still reports the server is using both SSL3 and SSL2.

I tried the apache2ctl -S command and it reports:

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 176.58.126.189. Set the 'ServerName' directive globally to suppress this message

VirtualHost: command not found

That first warning message appears a lot. I haven't tried to get rid of it yet except to see that ServerName is not the name of an existing command.

Anyway, it reports VirtualHost: command not found.

Any other ideas?

Thanks,

doug

You have not provided the information requested. You most likely have a configuration error.

Also, you should look at your error_log file for Apache to see what it says. It will report configuration errors in that when attempting to run. If there are errors, it will not run which sounds exactly what your problem is.

For starters, stop redacting your domain name.

If you're not serving an HTTPS site… what are you doing? Apache's SSL settings have absolutely nothing to do with your outbound HTTPS requests to somebody else's servers. You don't want or need to change anything in Apache's config for that.

If you're connecting to their system, you'd need to tell whatever you're using to do the connecting (PHP or whatever) not to use SSLv2 or v3 for the connection. That happens in your code, not in Apache.

You're getting weird errors from the scan and weird browser responses because you're serving HTTP on port 443:

❯ curl -I 'http://176.58.126.189:443'
HTTP/1.1 200 OK
Date: Thu, 08 Jan 2015 14:32:57 GMT
Server: Apache/2.4.7 (Ubuntu)
Connection: close
Content-Type: text/html;charset=UTF-8

Stop doing that, and you'll be fine.

Thanks for your message. The non-redacted full hostname is eldisodi.webcrossing.com.

I believe whether the server supports SSL3 is important because if it does then LinkedIn's API rejects connections from my server. My server at that point is acting like a client, and the client has to connect at TLS 1.0 or higher. If it support SSL3 then a fallback to SSL3 can occur because of the POODLE vulnerability.

LinkedIn (among others) is now rejecting SSL POST requests (e.g. to exchange an authentication code for an access token) if the request is coming from a server that supports SSL3, even if SSL is not turned on. I've been trying that for like two weeks now. You can read all about it in the LinkedIn blog for example. They say the only fix is to disable SSL3 on the server making the request, which is why I'm trying to set up a new server just to make these requests.

In their blog they wrote:

"In light of the recent disclosure of the "Poodle" SSL vulnerability, LinkedIn

is joining the large number of services that have actively removed support for

SSLv3, effective immediately. If you are experiencing errors related to

HTTPS-based communication with our APIs, please ensure you are using a

client/library that supports TLS 1.0+ instead of SSLv3 to avoid disruption."

and

"There is no fix for this issue. It is the result of an unfixable vulnerability

in the SSLv3 protocol itself, which is well outside of LinkedIn's control. We

will not be re-enabling support for this. You will have to use a library that

can make a different SSL connection."

I don't believe it's something I can specify in my request code. There is no header or anything for that. And everybody at LinkedIn and also stackoverflow insist the requesting server itself must disable SSL3.

In my case, since it is an outbound request, my server is acting like a client making a POST request. But because SSL3 is not disabled in my server the LinkedIn server refuses to handshake.

I'm serving ordinary http on port 80 I believe. If you go to http://eldisodi.webcrossing.com you can see the tiny test page there. That's on port 80, isn't it?

Thanks,

doug

@Dweeber:

You have not provided the information requested. You most likely have a configuration error.

Also, you should look at your error_log file for Apache to see what it says. It will report configuration errors in that when attempting to run. If there are errors, it will not run which sounds exactly what your problem is.

What information requested have I not provided. Obviously I have an error somewhere. :) But I don't know how to figure out where. When I restart the Apache service there are no syntax errors reported.

Anyway, the error.log file for my virtual server is empty.

Where is there an error_log file?

Thanks,

doug

You are not listening. This issue has absolutely nothing to do with Apache. Revert the changes you made to Apache, because you're now serving HTTP on both 80 and 443, when you should not be serving HTTP on 443.

Apache is not at all involved, nor do LinkedIn's statements claim that it is. They claim correctly that whatever client or library you use to connect to their API needs to do so via TLS 1.0 or better. That client or library would be whichever PHP library, bash command, or other thing you are running to connect to their server. Whatever tool that is needs to know to use TLS 1.0+. That said, it's going to try TLS 1.0+ first if it can, and it cannot fall back to SSLv3 because LinkedIn does not allow connections via SSLv3. So if your tool is throwing errors, make sure it actually supports TLS at all.

Leave Apache alone, it has no connection to this issue. Pastebin the actual code you're hitting LinkedIn's server with and the error you get back from that attempt.

• Les

While I greatly appreciate your replies, please don't say I am not listening. All I have been doing is listening for 2 weeks now trying to solve this problem.

First I started with another server besides Apache these last two weeks, but that server could not disable SSL3 and that was the cause of the problem. That server did support TLS1 though.

I do understand that I cannot make an SSLv3 connection to LinkedIn. What I am saying is that all the LinkedIn developers have been telling me that because my server (prior to trying Apache today) ALSO supports SSLv3 in ADDITION to TLS1 that the connection is being refused.

What can I say? I've round and round this point for 2 weeks over at StackOverflow, and that's what all the LinkedIn API developers insist is the case. The calling server, they say, must NOT support SSL3 even if it supports TLS 1.

So that's why I created this new Apache server today - so I would have a server free of SSL 3.

But if I go to a site like poodlescan it says SSL3 is enabled on the server.

I'm willing to start from zero again and wipe out Apache and do whatever is necessary. But from what I've heard from expert LinkedIn API people these last couple of weeks I do think the server has to be set to completely disable SSL3.

Right now my settings are so confused I don't know what to do anymore though.

But please don't again say "I'm not listening." It's a personal characterization that's not fair. I've been listening and trying everything people have been suggesting for 2 weeks now.

Thanks,

doug

One more point - I can't pastebin in the code I've been using to hit LinkedIn with because I haven't rewritten it into PHP yet. It is currently written in server-side JavaScript for my other server, which is a non-LAMP server.

doug

I'm telling you you're wrong. The thing that matters is SSL/TLS support in the code that actually makes requests at their API. Other servers running on the same system don't matter.

The scan says your Apache is affected because you're serving HTTP on port 443 and that's confusing the heck out of it.

The web server does not matter. It is not relevant. Stop messing with it.

Your code / client libraries are the issue. If they're in Javascript, paste the javascript. The issue here is with that, not with unrelated web servers.

• Les

Telling me I am wrong is something I can accept. :)

Obviously I'm doing something wrong.

But I will tell you this for sure: The server I was previously using supported at least TLS 1.0. And LinkedIn was rejecting my SSL POST calls because it detected an SSL 3 on my side.

Let's forget the JavaScript I am using at the other server because it is server-side JavaScript, not client-side JavaScript, and is not in widespread use, and won't run under Apache, so it won't help to post it here. But the contents of the POST request were correct and I could make the same POST request from that server to other servers and get a response with the data I sent, so I know the POST headers and body were correctly formed. I'm going to be translating it into equivalent PHP anyway (my entire purpose for setting up the new Linode today) and if I run into a problem with that I'll post about it.

So please let me ask you this, if you don't mind. I just removed Listening 443 from ports.conf and ran "a2dismod ssl" to turn off SSL (it reported that SSL was already disabled, which surprised me because following the Linode documentation I had earlier enabled it with a2enmod ssl and created a self-signed certificate. But anyway.). And I restarted the Apache service.

poodlescan is still reporting

Scan results

eldisodi.webcrossing.com:443 (176.58.126.189) - Vulnerable

This server supports the SSL v3 protocol.

This server supports the SSL v2 protocol. You should really disable this protocol. It's WAY deprecated.

According to your scan do you still see me serving HTTP on port 443? If so, can you suggest a way of turning that off. The only "443" I edited anywhere was the Listening line in ports.conf.

Thanks,

doug

I'm not going to help further if you aren't going to read what I'm saying.

Turn off Apache, it's not relevant here at all. Paste whatever code you're running that's talking to LinkedIn's API and the error it's returning.

• Les

@akerl:

I'm not going to help further if you aren't going to read what I'm saying.

Turn off Apache, it's not relevant here at all. Paste whatever code you're running that's talking to LinkedIn's API and the error it's returning.

• Les

I have to admit I'm shocked by your response and that you continue to say I'm "not reading what you are saying." Didn't I just try to rewind and turn off the listening on port 443 as you suggested? I was trying to be agreeable and forget about SSL and port 443 and try it your way!!! So I can't fathom why you wrote what you just wrote.

The error that LinkedIn API's returned was a failure to negotiate SSL 3. But since it is now you who are not reading what I'm saying you are probably right that we stop the conversation.

Is there anybody willing to try to help? I am willing to try any settings suggested. I really am.

And how can I use PHP without Apache? Sigh.

Thanks,

doug

Hmmmm…

The warning you saw on the blog was just that it has NOTHING to do with your Apache Web server or it's configuration.

Read the warning you posted before:

> In light of the recent disclosure of the "Poodle" SSL vulnerability, LinkedIn is joining the large number of services that have actively removed support for SSLv3, effective immediately. If you are experiencing errors related to HTTPS-based communication with our APIs, please ensure you are using a client/library that supports TLS 1.0+ instead of SSLv3 to avoid disruption.

Note it is talking about your CLIENT. That is what you are using to talk to them. Your Apache web server does not make connections to them, it receives connections to visitors to YOU.

So whatever software you are using to communicate to their API is what you should be looking at.

The issues with your Apache web server are completely separate from that issue and has nothing to do with what you are reading about the API you are attempting to connect to. If you are also having Apache issues, that is a different subject and has nothing to do with connecting to their API.

You have not provided as far as I can see any info on the CLIENT you are using to communicate to their API.

@douglerner:

And how can I use PHP without Apache? Sigh.

Yes.

@douglerner:

And how can I use PHP without Apache? Sigh.

By typing "php" at the command-line. The two are completely independent.

Thanks for your replies.

The client I had been using was a special server-side JavaScript with an integrated NoSQL object-oriented database on other previous server, which does not support PHP, but has a robust server-side JS with special methods for handling things like user objects, discussion objects, and a suite of methods for making http requests, direct object manipulation without serialization, etc.

The client (from LinkedIn's perspective) I want to try using is PHP to make the requests to the LinkedIn server.

So PHP will be acting like a client for me and making requests to the LinkedIn server.

I believe in this instance I can't just turn off or ignore Apache because, in addition to making server-side outbound requests, the LinkedIn API redirects users to a URL after the user grants permission. The redirected URL contains query parameters and the site to which the user is redirected has to accept the return and then call more "whatever language" (server-side JavaScript, PHP, Ruby, whatever) to make an SSL POST request to exchange the authentication code for the access token.

So it's intrinsic to this process that there be a web server running to listen for incoming requests and invoke the server-side language which does some important stuff.

While you can type PHP at the command line, I just don't see how we can divorce the fact that I need a properly functioning Apache server from the process. I can't just turn off Apache and still expect this API flow to work.

So all I was trying to do, at the end of this thread (which I admit was different from my original post after we had some conversation) is check to see if my Apache server is now set up correctly so I can add the needed PHP scripts to it.

While it is technically possible to use PHP at the command line I'm sure you can see how that would not be helpful in this situation and why I must invoke PHP functions, etc., from scripts running inside an Apache web server. And that's why I want to confirm that Apache is set up properly, which the last person said it was not. I made changes after those comments and now want to ensure that the settings seem correct to proceed. And if it's a PHP configuration needed to make sure I'm making the outbound request using TLS that's fine too. I just want to make sure what I need is configured properly.

Thanks,

doug

````
❯ curl -I http://eldisodi.webcrossing.com:443
HTTP/1.1 200 OK
Date: Thu, 08 Jan 2015 22:51:31 GMT
Server: Apache/2.4.7 (Ubuntu)
Connection: close
Content-Type: text/html;charset=UTF-8

````

Nope.

@akerl:

❯ curl -I http://eldisodi.webcrossing.com:443
HTTP/1.1 200 OK
Date: Thu, 08 Jan 2015 22:51:31 GMT
Server: Apache/2.4.7 (Ubuntu)
Connection: close
Content-Type: text/html;charset=UTF-8

Nope.

Thanks for your reply. So, getting back to this step now, what can I do to make sure it's listening on port 80? As I mentioned in my previous posts, I had previously changed exactly one file which referred to port 443. I had manually edited /etc/apache2/ports.conf (which gets included by apache2.conf) and has added the line:

Listen 443

at the top.

But I removed that last night (my time, it's early morning now), and the contents of ports.conf is what was there originally by default now:

Listen 80

Listen 443

Listen 443

And I did a

service apache2 start

after removing the extra Listen 443 line from the top.

Also, as I mentioned, I did a

a2dismod ssl

and confirmed that SSL was disabled from Apache.

Is there something else I can try to fix Apache so it's listening to the correct port?

Thanks,

doug

If you'd led with your actual question up front, this would have been way easier. Your fancy pants JS or PHP or whatever aren't the issue, it's the callback URLs you didn't get around to mentioning until now.

You need to serve HTTPS, and I'd bet you need a trusted cert too.

As I've said repeatedly, stop serving HTTP on port 443. You're serving HTTP on 80 just fine right now, and you're also serving it on 443 which is wrong. So enable SSL, set up your config to actually serve HTTPS on port 443 rather than duping your HTTP config.

• Les

@akerl:

If you'd led with your actual question up front, this would have been way easier. Your fancy pants JS or PHP or whatever aren't the issue, it's the callback URLs you didn't get around to mentioning until now.

You need to serve HTTPS, and I'd bet you need a trusted cert too.

As I've said repeatedly, stop serving HTTP on port 443. You're serving HTTP on 80 just fine right now, and you're also serving it on 443 which is wrong. So enable SSL, set up your config to actually serve HTTPS on port 443 rather than duping your HTTP config.

• Les

I had a misunderstanding of what the problem was at first, which is why I led with my original question. Now that that seemed to have been sorted I'm trying to solve the current problem. 20-20 hindsight is easy. In fact, after I finally find the solution one could say I didn't need to ask any question at all. :)

But I am confused now. Previously people were saying I don't need SSL on Apache, I shouldn't worry about the Apache settings, the outbound SSL POST request is all done in PHP, Apache has nothing to do with the requests to LinkedIn, stop worrying about SSL settings on Apache, forget about Apache, etc., etc., etc.

But now you are saying I "need to serve HTTPS" and might need a trusted cert too, and I need to enable SSL. But why? LinkedIn redirects just fine to non https URLs and has been redirecting to my other server without it being HTTPS.

To repeat - at my other server, which is not running HTTPS, redirects from LinkedIn are coming in just fine. The LinkedIn documentation says while they recommend the redirect URLs be https it is not required, and they let you set non-https redirect URLs for the apps you create.

For example, I can currently redirect a user to LinkedIn where they click the agreement to authorize access to their profile. LinkedIn then redirects the user back to my server to a non-https URL, and sends back a temporary authentication code as a query parameter. That works just fine.

The problem I was having with my "fancy pants JS" is not being able to then directly connect from my server to the LinkedIn API server because my server is attempting to connect outbound with SSL3, which LinkedIn no longer supports. Until I can fix that on my other server, I thought I'd try doing it with Apache and PHP.

But there is no reason to think that LinkedIn won't redirect to a non https:// URL. It's been doing that just fine.

So… getting back to the question at hand, do you (or anybody) happen to know why I'm also serving on port 443, which everybody seems to think is wrong, and which I'm trying to fix?

Thanks,

doug

I give up. I've told you several times that the issue is with your Apache configs, that you've got a config serving HTTP on port 443 and asked you to find it. I've asked for your Apache configs, which you didn't provide.

Either the error is due to the callback URLs and Apache's bad HTTPS, in which case fix that, or the error is what I originally said: totally unrelated to Apache, and entirely inside your code. I've now tried to explain both of them, and have been met with lots of ranting from you about how I don't know what I'm talking about.

If you read this thread again, instead of skimming and repeating your rant over and over, you'll find all the information you need to troubleshoot whichever of those two issues it actually is.

• Les

@akerl:

I give up. I've told you several times that the issue is with your Apache configs, that you've got a config serving HTTP on port 443 and asked you to find it. I've asked for your Apache configs, which you didn't provide.

Either the error is due to the callback URLs and Apache's bad HTTPS, in which case fix that, or the error is what I originally said: totally unrelated to Apache, and entirely inside your code. I've now tried to explain both of them, and have been met with lots of ranting from you about how I don't know what I'm talking about.

If you read this thread again, instead of skimming and repeating your rant over and over, you'll find all the information you need to troubleshoot whichever of those two issues it actually is.

• Les

I am not ranting. I'm trying to calmly answer and ask questions amidst conflicting advice.

I'm sorry you're giving up.

There is no error on this server yet. I haven't even gotten to the point of trying to make a call to LinkedIn from this brand new Apache/PHP server. I'm trying to first solve the problem which people said I have - apparently incorrectly listening to port 443. I've tried finding it and I can't, which is why I'm asking.

I have not seen any advice yet on exactly how to stop this errant port 443 listening. I've provided a copy of my ports.conf file.

Here is a pastebin of my apache2.conf file if you or anybody else are still interested in glancing at it.

http://pastebin.com/download.php?i=z64WbSA9

Please don't beat up on me if this is not the correct way to use pastebin. I've never used it before now.

Thanks,

doug

I went back to Linode support with this. They said there is nothing wrong my settings and:

"You don't need to disable listening on port 443. There is nothing bad about Apache listening there, it's simply a slightly different port that Apache operates on."

I am going to assume Support knows best and finish this discussion. Thanks to the people who tried to help. Sorry about the digression into port 443 brought up by some. But it appears to not be an issue.

Thanks,

Doug

When you went back to support did you tell them it was HTTP not HTTPS using 443? Akerl knows what he's talking about and was trying to help but you didn't follow through.

@arlen:

When you went back to support did you tell them it was HTTP not HTTPS using 443? Akerl knows what he's talking about and was trying to help but you didn't follow through.

Yes I explicitly explained that to support and showed them my links and config files and the curl command and output shown in this discussion. And that was their reply.

I don't know why you say I didn't follow through on advice offered here. I followed through on everything.

Regards,

Doug

As a final note here, it does seem Linode support was correct. I was able to create the PHP scripts to connect with the LinkedIn API and am successfully connecting and getting full profiles back after a user grants authorization.

So there are no current problems.

Again, thanks for the help people.

doug

For what it's worth, akerl used to be a member of Linode Support.

@douglerner:

As a final note here, it does seem Linode support was correct. I was able to create the PHP scripts to connect with the LinkedIn API and am successfully connecting and getting full profiles back after a user grants authorization.

So there are no current problems.

Again, thanks for the help people.

doug

Your Apache configuration is still wrong. You need to stop serving HTTP traffic on port 443 (which is meant for SSL only).

Plus I can access your access.log and error.log from the website which you really really want to stop.

So you need to fix your Apache config as well (as many other people have said in this thread).

I don't know what to say about the HTTP traffic on port 443 issue. Linode support disagrees.

I'll check about blocking access to access.log and error.log. Thanks for pointing that out.

doug

@Cromulent:

@douglerner:

As a final note here, it does seem Linode support was correct. I was able to create the PHP scripts to connect with the LinkedIn API and am successfully connecting and getting full profiles back after a user grants authorization.

So there are no current problems.

Again, thanks for the help people.

doug

Your Apache configuration is still wrong. You need to stop serving HTTP traffic on port 443 (which is meant for SSL only).

Plus I can access your access.log and error.log from the website which you really really want to stop.

So you need to fix your Apache config as well (as many other people have said in this thread).

How are you viewing the access.log and error.log so I can confirm I can block it?

Thanks,

doug

@douglerner:

@Cromulent:

@douglerner:

As a final note here, it does seem Linode support was correct. I was able to create the PHP scripts to connect with the LinkedIn API and am successfully connecting and getting full profiles back after a user grants authorization.

So there are no current problems.

Again, thanks for the help people.

doug

Your Apache configuration is still wrong. You need to stop serving HTTP traffic on port 443 (which is meant for SSL only).

Plus I can access your access.log and error.log from the website which you really really want to stop.

So you need to fix your Apache config as well (as many other people have said in this thread).

How are you viewing the access.log and error.log so I can confirm I can block it?

Thanks,

doug

http://eldisodi.webcrossing.com:443/eld … access.log">http://eldisodi.webcrossing.com:443/eldisodi.webcrossing.com/log/access.log

http://eldisodi.webcrossing.com:443/eld … g.com/log/">http://eldisodi.webcrossing.com:443/eldisodi.webcrossing.com/log/

http://eldisodi.webcrossing.com:443/eld … ssing.com/">http://eldisodi.webcrossing.com:443/eldisodi.webcrossing.com/

http://eldisodi.webcrossing.com:443/

Thanks. I'll check about blocking those.

doug

@douglerner:

I don't know what to say about the HTTP traffic on port 443 issue. Linode support disagrees.

I hate to contradict people who know more about Linux than myself but if they said it was fine and OK to serve HTTP (and not HTTPS) on port 443 they were wrong.

@Cromulent:

@douglerner:

I don't know what to say about the HTTP traffic on port 443 issue. Linode support disagrees.

I hate to contradict people who know more about Linux than myself but if they said it was fine and OK to serve HTTP (and not HTTPS) on port 443 they were wrong.

Perhaps so. I'm discussing it with them again.

Thanks,

doug

@douglerner:

@Cromulent:

@douglerner:

I don't know what to say about the HTTP traffic on port 443 issue. Linode support disagrees.

I hate to contradict people who know more about Linux than myself but if they said it was fine and OK to serve HTTP (and not HTTPS) on port 443 they were wrong.

Perhaps so. I'm discussing it with them again.

Thanks,

doug

To be more precise: You can serve HTTP on any port if you want, but in 99.999% of cases you'll want to be serving HTTPS on port 443 because that's what the rest of the world expects.

Kinda like how your car will physically be able to drive the wrong way on the highway, but people might be surprised if they come across you.

Well, for some reason all the things Support asked me to try didn't work, and the directories were still exposed via port 443. We closed all the Listening to 443 in all the Apache configuration files, but it didn't seem to make a difference.

But I just tried this myself and it seems to have worked, and is not adversely affecting my PHP API to LinkedIn:

1. I edited /etc/iptables.firewall.rules

2. I commented out the line

-A INPUT -p tcp –dport 443 -j ACCEPT

3. I ran the following command:

iptables-restore < /etc/iptables.firewall.rules

That seems to have worked. I believe you cannot get to the log files or see the index via 443 now. Anybody feel like confirming?

I think instead of commenting out the ACCEPT line I could have just changed ACCEPT to DROP. Would that have been preferable?

Thanks,

doug

````
apache2ctl -S

````

• Les

@akerl:

apache2ctl -S

• Les

Sorry. Can you tell me what you are asking me to do? Are you saying to use that command instead of what I did with the IP tables? Or in addition to what I've already done?

Thanks,

doug

I asked for the output of that command at the beginning of this adventure, and I'm asking for it again now.

Blocking port 443 at iptables is a bandaid over the real problem, and if there's ever an issue that prevents the firewall rules from loading in the future or negates that rule, your misconfigured virtualhost will be exposed again.

• Les

@akerl:

I asked for the output of that command at the beginning of this adventure, and I'm asking for it again now.

Blocking port 443 at iptables is a bandaid over the real problem, and if there's ever an issue that prevents the firewall rules from loading in the future or negates that rule, your misconfigured virtualhost will be exposed again.

• Les

I see. Sorry, I did not notice your previous request. Here is the output of that command:

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 176.58.126.189. Set the 'ServerName' directive globally to suppress this message

VirtualHost configuration:

*:80 eldisodi.webcrossing.com (/etc/apache2/sites-enabled/eldisodi.webcrossing.com.conf:4)

ServerRoot: "/etc/apache2"

Main DocumentRoot: "/var/www"

Main ErrorLog: "/var/log/apache2/error.log"

Mutex default: dir="/var/lock/apache2" mechanism=fcntl

Mutex mpm-accept: using_defaults

Mutex watchdog-callback: using_defaults

PidFile: "/var/run/apache2/apache2.pid"

Define: DUMP_VHOSTS

Define: DUMPRUNCFG

User: name="www-data" id=33

Group: name="www-data" id=33

And you've restarted Apache since changing your configs? What's in /etc/apache2/sites-enabled/eldisodi.webcrossing.com.conf ? Also /etc/apache2/ports.conf?

Yes, after changing config files I always run

service apache2 start

Here are the other contents.

/etc/apache2/sites-enabled/eldisodi.webcrossing.com.conf

domain: example.com

public: /var/www/example.com/public_html/

# Admin email, Server Name (domain name), and any aliases

ServerAdmin doug@elliptics.com

ServerName eldisodi.webcrossing.com

ServerAlias eldisodi.webcrossing.com

Index file and Document Root (where the public files are located)

DirectoryIndex index.html index.php

DocumentRoot /var/www/eldisodi.webcrossing.com/public_html

Log file locations

LogLevel warn

ErrorLog /var/www/eldisodi.webcrossing.com/log/error.log

CustomLog /var/www/eldisodi.webcrossing.com/log/access.log combined

Options -Indexes

/etc/apache2/ports.conf

If you just change the port or add more ports here, you will likely also

have to change the VirtualHost statement in

/etc/apache2/sites-enabled/000-default.conf

Listen 80

# Listen 443

# Listen 443

vim: syntax=apache ts=4 sw=4 sts=4 sr noet

You realize, of course, that "service apache2 start" starts apache2, it doesn't restart it?

You want "service apache2 restart".

• Les

@akerl:

You realize, of course, that "service apache2 start" starts apache2, it doesn't restart it?

You want "service apache2 restart".

• Les

Actually, I did not realize that. Let me try and undo the IP table thing and try the restart.

(pause to try)

I just did the following:

1. I edited vi /etc/iptables.firewall.rules and restored it to its original configuration, where there is a line

-A INPUT -p tcp –dport 443 -j ACCEPT

in it and ran

iptables-restore < /etc/iptables.firewall.rules

Immediately after doing that I could see the directory with a 443 connection again.

2. I ran

service apache2 restart

Immediately after that I got a failure to connect with a 443 connection.

And my PHP API is still working on port 80.

Thank you very much. I'm very grateful. I'm sorry for any confusion I caused by my inexperience with this.

I guess this seems ok now, right?

Regards,

doug