Making SSL/HTTPS requirement optional for intranet use

[Chalew Tesfaye]

I have installed Dspace 7.2 and working fine from the localhost domain. When I try in production I end up with a 403/forbidden error and actually, the documentation says it has to be configured with HTTPS. I tried a self-signed certificate, still I didn't get right. Is there a way/configuration that makes SSL/HTTPS requirements optional for intranet use? 

Your comment ...

Thanks in advance.

[Tim Donohue]

Hi,

Unfortunately, the only way to run DSpace 7 via HTTP is via "localhost" URLs (which is similar to a development mode).   Otherwise, your user's browsers may accidentally block important Cookies (especially the XSRF token) from being sent back to the REST API, causing an inability to login (which is a 403 error). This is usually the result of a user's web-browser strictly *blocking* those Cookies, unless they are sent via HTTPS.  It's a security protection of modern web browsers.

So, we are not aware of anyway to get around this and run DSpace via HTTP in production.  It's much easier (and more secure) to buy an inexpensive SSL cert, or use a free service like Let's Encrypt: https://letsencrypt.org/

Tim

[Mohammad S. AlMutairi]

  It's a very bad idea to run Dspace or any other service unsecure ( Traffic including login credentials can be sniffed very easily ) but if you insist on doing it It's possible to run it via HTTP ( See the setup that should work for you below ). The issue with the latest browsers builds ( Chromium based browsers and the rest of the gang ) is if the services run in a mixed mode specially downgrading from HTTPS ---> HTTP. but HTTPS <----> HTTPS or HTTP <----> HTTP Should work just fine.

• You don't need a webserver for this to work so you must stop the webserver and disable it or even uninstall it if you wish.
• The two points you see below must be done if you don't have a local DNS server for the dspace server and the clients accessing the dspace server to resolve the dspace server name to its IP address.
  
• You need to tell the server about itself by adding a host entry into /etc/hosts file. As an example assuming the dspace server ip address is 10.0.10.10 and its name is dspace.intranet.net the entry in the hosts file should be  (  10.0.10.10   dspace.intranet.net ).
• You need to tell the client/workstation how to reach the dspace server. You can add a similar entry as above into the client PC hosts file in Linux it should be in /etc/hosts and in Windows should be in C:\Windows\system32\drivers\etc\hosts ..

in dspace.cfg or local.cfg set:
dspace.server.url = http://dspace.intranet.net:8080/server
dspace.ui.url = http://dspace.intranet.net

Note that I'm using port 80 here.
in config.prod.yml set:
ui:
  ssl: false
  host:  dspace.intranet.net
  port: 80
  # NOTE: Space is capitalized because 'namespace' is a reserved string in TypeScript
  nameSpace: /
  # The rateLimiter settings limit each IP to a 'max' of 500 requests per 'windowMs' (1 minute).
  rateLimiter:
    windowMs: 60000 # 1 minute
    max: 500 # limit each IP to 500 requests per windowMs

# The REST API server settings
# NOTE: these must be 'synced' with the 'dspace.server.url' setting in your backend's local.cfg.
rest:
  ssl: false
  host:  dspace.intranet.net
  port: 8080
  # NOTE: Space is capitalized because 'namespace' is a reserved string in TypeScript
  nameSpace: /server

Test the connection using yarn test:rest and then just build the frontend and once it finished the build process point your browser to http//dspace.intranet.net/ and it should work without any issue including the logging in.

On Friday, February 25, 2022 at 3:51:12 PM UTC+3 chale...@gmail.com wrote:

I tried a self-signed certificate, still I didn't get right.

Here is how it should be done to work.

• The two points you see below must be done if you don't have a local DNS server for the dspace server and the clients to resolve the dspace server name to its IP address.
  
• You need to tell the server about itself by adding a host entry into /etc/hosts file. As an example assuming the dspace server ip address is 10.0.10.10 the entry in the hosts file should be  (  10.0.10.10   dspace.intranet.net ).
• You need to tell the client/workstation how to reach the dspace server. You can add a similar entry as above into the client PC hosts file in Linux it should be in /etc/hosts and in Windows should be in C:\Windows\system32\drivers\etc\hosts ..

You need to build a SAN certificate to satisfy the recent chromium based browsers. Chrome will generate an error if you use a common name only in the self signed certificate.

1) Create a san file call it san.cfg that contains:

[req]

distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = COUNTRY-NAME-HERE
ST = STATE-OR-PROVINCE-HERE
L = CITY-NAME-HERE
O = ORGINZATION-NAME-HERE

OU = DEPARTMENT-NAME-HERE
CN = intranet.net
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.intranet.net
DNS.2 = dspace.intranet.net
DNS.3 = cms.intranet.net
DNS.4 = smtp.intranet.net
DNS.5 = idp.intranet.net
DNS.6 = sp.intranet.net

2) Build a 10 years certificate with its key in the local directory using:

a) openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout ./server.key -out ./server.crt -config san.cfg -extensions 'v3_req'

b) chmod 600 server.key

3)  Copy the files to its final location & add the certificate and its key to the webserver as usual.

4) During the frontend connection testing yarn test:rest the testing will fail with the following error ( Error: self signed certificate ) to overcome this error you must execute the two commands (a) and (b) you see below. It's good for testing the connection, building and starting the frontend manually but you need to add Environment="NODE_EXTRA_CA_CERTS=/PATH-TO/server.crt" to the frontend systemd startup script in the [Service] section if that's how you are going to start the frontend during the boot.

a) echo "export NODE_EXTRA_CA_CERTS=/PATH-TO/server.crt" >> /etc/environment

b) source /etc/environment

5) Assuming the client is a Windows machine the final step to make all of this workable is to add the self signed certificate (server.crt) to the Trusted Root Certification Authorities using mmc.exe, certlm.msc or using the browsers themselves. In Chrome ---> Settings ---> Security ---> Manage certificates ---> Click on Trusted Root Certification Authorities and Choose Import.

Thanks in advance.

You welcome. 

[Mohammad S. AlMutairi]

Occasionally I see some posts in this list asking if it's possible to run DSpace without having to go the HTTPS path and the answer is yes you can. I'm attaching a confirmation which I received from this thread creator (Chalew Tesfaye) but it never found it's way here, I'm also attaching a video which I made tonight after spinning up a new server and installing the latest DSpace 7.5-Snapshot on it just to let you know it works.

Hope it help someone who needs it.

[Tim Donohue]

Thanks for sharing this! I didn't realize you could bypass HTTPS restrictions built into modern browsers in this manner.  

I would still *never recommend* this approach, even for intranet usage. It's obviously a massive security issue for any production quality system. As you rightly noted, it's a very bad idea since everything will be sent in plain text. This means that a malicious user on your intranet could sniff traffic to steal passwords and (possibly) even steal your authenticated session (via information found in unsecured cookies).

So, good to know it's an option if people really want this. But, I can never recommend it for any production-like scenarios. :)  HTTPS is required for your site to be secure. Anyone can generate a free HTTPS certificate using services like Let's Encrypt: https://letsencrypt.org/ ("certbot" tool) and there are plenty of guides out there around using Let's Encrypt with whatever webserver you choose (Apache, Nginx, etc).  For example, EFF provides instructions for using/installing certbot for HTTPS based on your OS and webserver: https://certbot.eff.org/

Tim