Small oddity re /~ access

Hello,

This is actually a new feature :)

In previous versions of DirectAdmin all ~user requests were not calculated into the respective users' bandwidth tally. This obviously was unacceptable.

The latest DA version fixes this: requests via hostname/~user and IP/~user are logged, and, due to apache limitations, domain/~user requests are disabled.

Phi1.
 
OK. I know I thought this was a good idea to begin with but we've discovered that this feature comes at a considerable cost.

By not allowing this feature you've also (knowingly or not) prevented admins from allowing users to use server SSL certificates as shared certs.

On my previous DA box, I could let all users on that server share the server's SSL cert by using the following syntax:

https://www.serverdomain.com/~user

With the new mods in the new version of DA, I can no longer do this - it just generates a "page not found" error.

Can someone tell me how I'm supposed to allow my users to share the server certificate if /~ has now been disabled?

Or, if there is another way to approach this?

Many thanks!
 
You could put the cert you want to share on the server ip instead of on the primary domain I think.

But it does cause a small inconvenience.
 
jmstacey said:
You could put the cert you want to share on the server ip instead of on the primary domain I think.
Click to expand...
I'm not sure what you mean, Jon. How would you do that?

Jeff
 
I don't know how you would do that. Just an idea I had but I don't know if its possible.

Users previously used domain/~username to access their sites but now use serverip/~username
So why not put the secure certificate on the serverip address. (if its possible)
In theory it would work just like before except through the ip addess instead of the domain.
 
So then you leave us with two questions:

1) will a certification authority issue a signed certificate for an IP#?

2) will we all want to go out and buy new certificates.

Actually there's another way to solve the problem.

Okay, I'll go write another How-To.

I'll come back and post when it's done.

Jeff
 
What version of DA are you running?

With old versions of DA both the hostname and the sitename for the admin site worked.

With the latest version the hostname still works but the sitename doesn't.

The problem exists for those of us who want to host shared certs at our sitename rather than at our hostname; for example resellers who'd rather host shared secure sites at secure.reseller.com than at (for example) host.systemdomain.com.

Jeff
 
jlasman said:
Okay, I'll go write another How-To.

I'll come back and post when it's done.
Click to expand...
The How-To is done; it can be found in the How-To forum; it's called "Using Shared Certificates".

Jeff
 
Jlasman, does your howto also get around the original problem so all users can share the admins or resellers certificate?
 
Hey,

OK, I guess I see a little clearer now... We're on DA 1.222

Our cert is setup using the hostname as there is no sitename since there is NO admin domain. (We installed the cert manually)

So, the reseller or user would use the hostname of the server along with /~username to share the cert. Obviously, it's not seamless for a reseller.

For us this currently works well as there are no resellers on this box...

However, our reseller solution will be somewhat like Jeff details in that we will use a neutral domain and build the cert and server around that... At least that's what I'm thinking will work...

Basically, server hostname will be something like:

secure01.neutraldomain.com

and resellers/users should be able to use:

secure01.neutraldomain.com/~username

for sharing the server cert as well as logging in to DA.

Comments are welcome.

David
 
I am looking for resolution to a similar problem:
just like ~user requests were not calculated, /phpmyadmin/, /webmail/ and other similar requests can be performed thru any domain resolving to the given server.
 
Because they're server-wide shared services.

I don't really see any simple way to secure these given the current architect of DirectAdmin.

The only way I see to do it would be to have a completely separate installation of each service for each domain.

Jeff
 
jlasman said:
Because they're server-wide shared services.

I don't really see any simple way to secure these given the current architect of DirectAdmin.

The only way I see to do it would be to have a completely separate installation of each service for each domain.

Jeff
Click to expand...

Well, since there is a way to get a script executed on user creation, it's possible to automatically install a copy of these services in password protected directory, but I don't think it worth the trouble :)

I think forcing users to use a single ("admin") domain is sufficient in the sense that no user is charged for bandwidth he/she doesn't use.
 
You must log in or register to reply here.
Back
Top