Change the auto logoff time

Donnti · October 28, 2021, 11:41pm

Is there a way I can change the auto logoff time for both Nodeworx and Siteworx? As I have been doing a lot of stuff getting my domains up and running, I will be working with a different program then come back to either page, and I have to relog in. I want to extend the auto logoff time, so I do not have to relog back on after a couple of minutes of no activity.

IWorx-Jenna · October 29, 2021, 12:56am

Hello—

The setting is located in ~iworx/iworx.ini. It is idle_timeout, under the [session] header. It should be set to 1200 by default–the setting is in seconds (so the default is about 20 minutes).

Thanks,
-Jenna
Friendly Neighborhood InterWorx Support Manager

Donnti · October 29, 2021, 1:28am

Thank you Jenna.

I do have another question, I followed the steps from forums.interworx-com/t/letss-encrypt-ssl-for-server-name/15303(can’t post links so I changed the format) but when I log into the Nodeworx it isn’t secure. I can log into the siteworx and that is secure. What do I need to do? I did change the URL from the IP to the domain name.

d2d4j · October 29, 2021, 7:10am

Hi

The Interworx-SSL needs to have the correct SSL

We always use the server FQDN SSL for all services, so if say the server FQDN was myserver.url, and mail was mail.myserver.url, webserver was myserver.url and www.myserver.url and FTP was ftp.myserver.url

You would generate the SSL using Lets Encrypt to cover myserver.url, www.myserver.url, mail.myserver.url and ftp.myserver.url and then set nodeworx server SSL to use the siteworx domain myserver.url SSL

This then covers all services and is easy to update, as nodeworx SSL uses siteworx SSL, which auto updates the SSL, and thereby keeping the nodeworx SSL uptodate

If this is not the issue, you would need to give more details.

If you prefer, you could PM me the nodeworx link and I can test externally

Many thanks

John

IWorx-Jenna · October 29, 2021, 12:36pm

Hello–

I would not recommend using the method in that forum post, really.

Here is our documentation on how to generate SSL certificates for system services: How to: Manage SSL Certificates For System Services — InterWorx documentation

The recommended way is to use Let’s Encrypt to generate the SSLs using the hostname (this requires that the hostname domain a) resolves to the server and b) is not a SiteWorx account): How to: Manage SSL Certificates For System Services — InterWorx documentation

Then you would access NodeWorx with

https://hostname.com:2443/nodeworx

and SiteWorx with

https://hostname.com:2443/siteworx

And both will be covered. Also, it will automatically renew itself (which the method in that old forum post will not).

If you want to know the method in the forum post, of applying a domain-level SSL to system services, is the domain that you used ALSO the hostname of the server?

It is recommended to first always check our documentation for instructions before checking the forum, since a lot of posts on the forum can be out of date. Our documentation is located at docs.interworx.com, which redirects to the appendix link above.

d2d4j · October 29, 2021, 1:03pm

Hi @IWorx-Jenna

I am sorry, are you sure using siteworx domain for nodeworx SSL settings does not autogenerate/update

We have been using LE that way for since it was introduced and have never had any issues or manually had to generate the SSL once setup and also, as we need access to the server FQDN email, a siteworx easily covers this whereas I thought allowing nodeworx server generated LE to cover services would not allow email facilities

It may have changed on IW7 perhaps, but I hope not

@Donnti does need to provide more details to fully understand his issue though, as I did not think you could separate /nodeworx from /siteworx apart from if you change in iworx.ini but why would you

Many thanks

John

IWorx-Jenna · October 29, 2021, 1:59pm

Hello–

The cert in SiteWorx will automatically renew, but as far as I’ve always been aware, it had to be manually re-applied to the system services every three months. That was part of the whole reason we set up an option to generate an LE cert for system services, using the hostname, directly. So I am surprised that you have never had to re-apply the domain-level SSL cert to system services (meaning, navigate to Server > SSL and click “update certificates”).

I don’t know what you mean by “would not allow email facilities”. Could you clarify?

Thanks,
-Jenna

d2d4j · October 29, 2021, 2:18pm

Hi Jenna

Many thanks

Sorry if you choose to use siteworx SSL it requires no manual update

This is how it LE was originally used for nodeworx SSL and rsync from siteworx SSL. The reason for the direct nodeworx SSL LE was users were asking for that as they did not want to setup a siteworx account

If there is no siteworx account there is no email account for ted server FQDN.

Yo use email on server FQDN requires a siteworx account

Many thanks

John

IWorx-Jenna · October 29, 2021, 2:56pm

Hello–

Again, that is not how it was originally set up, but maybe something changed in the last few years and I was unaware (I had so, so many support tickets running into that issue, where they had to manually update the System SSL certs to apply the new domain-level SSL to it every three months). Most folks stopped using that method a few years ago, once we added the new way of doing it (2019 or so?), so I may just not remember that changing.

I don’t know what you mean by “If there is no siteworx account there is no email account for ted server FQDN”.

The mail services can use the hostname for their SSLs without any issue. A SiteWorx account is not needed for that. You can use the hostname for the mail service FQDN. That is what most folks seem to do. You do not need to have a SiteWorx account for the hostname for mail services–you never really did (or at least not in the six years I’ve been around. Maybe it was different prior to that). It just has to resolve to the server.

Thanks,
-Jenna

d2d4j · October 29, 2021, 3:23pm

Hi Jenna

Many thanks

In the very early days that was correct and a lot of users did not understand

You can use nodeworx SSL LE as you post or use a siteworx domain for SSL. This then updates nodeworx SSL

Sorry the email was not for mailserver SSL

It is if you need email accounts on the server FQDN

Many thanks

John

IWorx-Jenna · October 29, 2021, 3:35pm

Hello–

I think I’m still not understanding.

Yes, if you want email accounts on the server, they have to be associated with a SiteWorx account.

The FQDN listed on the MTA page in NodeWorx (which is what I am referring to) does not have to be a SiteWorx account. You never have to make a SiteWorx account for the hostname in order for mail services, in general to work.

Thanks,
-Jenna

d2d4j · October 29, 2021, 7:36pm

Hi Jenna

Sorry I think I may have taken off topic slightly but just needed to be sure that using a siteworx account for nodeworx SSL was still in use. I think your support tickets over manual renewal were more to do with users not implementing code similar to this thread from 2016.

Server SSL Certificate via LetsEncrypt - NodeWorx / General Discussion - Interworx Forum

It was not long after that nodeworx SSL could be generated using LE but also use a siteworx account, which I think just changes the location of the SSL files

Anyway sorry for taking off topic

Donnti issue is /siteworx is secure but /nodeworx is not

After thinking about this, it could be stale browser cache but woudl need more details

Hopefully donnti will post back or open a support ticket

Many thanks and hope you have a lovely weekend

John

IWorx-Jenna · October 29, 2021, 8:15pm

Hello–

Oh, okay, yeah, a custom code like that would explain why the functionality is different than the default. Good to know someone came up with that.

-Jenna

sysnop · January 21, 2025, 3:57am

Hello, and sorry for the bump.

Let’s Encrypt verifies and issues my server hostname and domain certificates just fine but I’m struggling with this part…

To use the example above – Firefox will say SSL_ERROR_BAD_CERT_DOMAIN, Edge will say net::ERR_CERT_COMMON_NAME_INVALID and so on. The server certificate with :2443/nodeworx works fine as there’s no mismatch.

What could I be missing to get Siteworx URLs to properly use the server’s Let’s Encrypt certificate for the ‘Interworx-SSL’ service (which I assume means port 2443)?

Interworx hosts DNS for the server hostname in a manually added zone. The same domain is used for nameservers. Aside from SOA the only records are A/AAAA and NS and resolving hasn’t been a problem. Would I be better off hosting these DNS records outside of Interworx?

d2d4j · January 21, 2025, 9:16am

Hi sysnop

I think your getting a little confused or overthinking but I could be wrong sorry

The port 2443 is nothing to do with SSL other then it is port used for IW CP login secure

I suspect your siteworx accounts may not have their own SSL cert or self signed cert

IW-CP should rewrite requests to siteworx login and use the domain to auto fill the domain box once login page has been shown

It should work both for secure and insecure so maybe try using none secure http and not https to see if that rewrite works and takes it through to serverFQDN:2443/siteworx login screen

If above works, the secure should work in same way unless the first call to siteworx domain secure has an issue with its SSL cert

Many thanks

John

IWorx-Jenna · January 21, 2025, 4:03pm

Hello–

Can you provide a bit more detail?

Are you using the hostname in the URL or the SiteWorx domain?

If you are using https://hostname.com:2443/siteworx, I would expect for that to show as covered, since the SSL cert for the hostname in NodeWorx under Server > SSL Certificates covers port 2443 (the internal Apache instance for InterWorx)

If you are using https://siteworxdomain.com:2443/siteworx, that will never show as covered/would get a mismatch. This is because, again, :2443 is the port for the internal Apache instance for InterWorx.

The SSL for siteworxdomain.com that is listed in SiteWorx covers port 443.

And siteworxdomain.com is not covered by the SSL cert under System Services for 2443–only the hostname is.

If you are seeing that https:hostname.com:2443/siteworx is showing as a cert mismatch or not covered, but https://hostname.com:2443/nodeworx IS showing as covered, please submit a ticket because I’d like to take a look at that, as I have no idea how that would be happening.

Thanks,
-Jenna

sysnop · January 21, 2025, 6:47pm

I think you are right, there are small details that grow big in my mind. I think I’m getting my act together, though. Btw, http redirects and other things you mentioned work as they should.

sysnop · January 21, 2025, 6:52pm

Hi Jenna,

I think you’ve helped me understand better. Mainly that my problem is a non-problem. First off, the part of my post above that quotes you, specifically “hostname.com:2443/siteworx” – was a late night, dry-eyed error on my part. I interpreted that as a Siteworx URL and reacted too quickly. Sorry for the distortion, although you picked up on what I tried to describe anyway despite my mistake.

This is the gem I’ve been digging for. I thought a certificate covering ‘Interworx-SSL’ applied to port 2443 in a broader way – Siteworx in addition to Nodeworx.

So, if a Siteworx user puts https:/siteworxdomain.com:2443/siteworx in their browser, there’s not supposed to be a valid certificate, is that right? And if the user wants a valid certificate they need to use the server hostname URL instead. If that’s the case, I’m mostly all good and no need to dig further. I can see the logic in why it works that way, I simply thought the server certificate was supposed to cover Siteworx URLs.

The good news is what you and John say should work is working. The only remaining rub is a name mismatch depending on how I go about the server hostname certificate. Over the years this has come up a lot – whether to do it with or without a Siteworx account for the server hostname. With this recent Interworx installation I’ve tried both methods.

As it is now I’m relying on just a few DNS records, no Siteworx account for the hostname, and Let’s Encrypt validates. But when doing it this way browsers are served the wrong certificate from a Siteworx domain on the same shared IP. I haven’t figured out why unless something is amiss with SNI, or unless Default Sites has an effect I don’t understand (all set to /var/www/html for now).

If I create a Siteworx account for the server hostname and source the certificate that way, SSL is valid and no browser warning.

Thank you.

IWorx-Jenna · January 21, 2025, 7:43pm

Hello–

‘Interworx-SSL’ does cover both /nodeworx and /siteworx (and /webmail), so you are correct, there. It just does so over port 2443.

So that SSL cert covers the domain it is associated with–the hostname of the server–over 2443, which covers:

2443/nodeworx
2443/siteworx
2443/webmail

The mismatch is that siteworxdomain.com doesn’t exist on port 2443. Meaning, in the vhost for siteworxdomain.com, there isn’t a 2443 section. Just 80 and 443–the ports used for Apache in the outside world.

So when you navigate to https://siteworxdomain.com:2443/siteworx, Apache looks at the vhost for siteworxdomain.com, to see if there is an SSL cert for that port.

Since it doesn’t see a 2443 section, so it doesn’t have an SSL cert associated with siteworxdomain.com to serve.

Apache then looks further up the chain and sees there is a SSL for hostname.com over 2443, so it gives that. But since siteworxdomain.com =/= hostname.com, that cert works for giving some kind of information over https, but there is a mismatch on for the cert being served.

But you are correct, in order to have a secure connection over https for /nodeworx, /siteworx/ and /webmail, users need to use https;//hostname.com/siteworx, instead of siteworxdomain.com/siteworx.

Alternately, there is a slight change you can make to the server:

Create a new file named under /etc/httpd/conf.d called 10-iworx.conf
In the file, add the following, replacing hostname.com with the hostname of the server:

RewriteEngine on
RewriteRule ^/siteworx(/)?$ https://hostname.com:2443/siteworx/\?domain=%{HTTP_HOST} [R,L]
RewriteRule ^/nodeworx(/)?$ https://hostname.com:2443/nodeworx/ [R,L]

Restart Apache

systemctl restart httpd

.
That will force https://siteworxdomain.com/siteworx to redirect to https://hostname.com:2443siteworx, which is then covered by the SSL cert for the internal Apache instance. No concerns about mismatches, because it will just redirect to the expected URL.

Can you provide a bit more information regarding “But when doing it this way browsers are served the wrong certificate from a Siteworx domain on the same shared IP.”

Does that SiteWorx domain also have an SSL cert?

Thanks,
-Jenna

d2d4j · January 21, 2025, 9:08pm

Hi

The rewrite rule iw Jenna shows is correct and works lovely that’s how our servers are set and saves a lot of time

Just 1 point you need to add a third line for /webmail so it covers all

Many thanks

John