Tomcat Cert Process for Dspace

[Dayne Ellanna]

I am having the worst time getting tomcat to do https for dspace.  I followed the instructions on the dspace site but cannot make heads or tails of the instructions as I am definitely not a certificate expert.  The instructions use generic names and don't explain where root ca's come from or generating certificate requests and from what do I generate these.  Can someone give me very specific instructions about how to set up the https on tomcat to run dspace.  So far I have gotten dspace to run successfully as http://myserver.domain:8080/xmlui.  As per instructions on the dspace site I have tried to create the RSA key, and we use incommon for our certs which I can obtain, but have not been able to figure out the beginning to end process for this.  I tried using curl to test but no success.  I really need a succinct explanation of all the pieces, where to get them or how to generate them in order to run the ssl.  HELP!

Thanks,

Dayne

[Tony Brian Albers]

Dayne,

We proxy tomcat behind apache httpd to solve this exact issue. Our
tomcat listens on port 8877.
If you want to try that, in short what you will need is to install httpd
and set it up to run ssl. Then you can define a ssl-enabled virtualhost
in apache that proxies your tomcat. Here is our httpd conf file for the
virtualhost, I've added my comments in ### (with sensitive bits changed,
but still in the right places):



# Default host when using NameVirtualHost
<VirtualHost *:80>
### ^ this creates a httpd server listening on port 80.
ServerAdmin help...@mydomain.edu
DocumentRoot /var/www/html
ServerName dspace-devel.mydomain.edu
ServerAlias dspace-devel

ErrorLog logs/dspace-devel.mydomain.edu-http-error_log
CustomLog logs/dspace-devel.mydomain.edu-http-access_log combined

ProxyPass / http://127.0.0.1:8877/ retry=10 connectiontimeout=5
### ^ this tells httpd to redirect it's / to localhost port 8877
timeout=300
ProxyPassReverse / http://127.0.0.1:8877/ retry=10
### ^ this tells httpd that tomcat's url's should be rewritten to look
### like they're coming from httpd.
ProxyPreserveHost On
### ^ this tells httpd to keep the Host: information from the client and
### pass it on to tomcat.

</VirtualHost>

<VirtualHost dspace-devel.mydomain.edu:443>
### ^ this creates a httpd server that listens on port 443.
ServerAdmin help...@mydomain.edu
DocumentRoot /var/www/html
ServerName dspace-devel.mydomain.edu
ServerAlias dspace-devel

ErrorLog logs/dspace-devel.mydomain.edu-https-error_log
CustomLog logs/dspace-devel.mydomain.edu-https-access_log combinedssl

Include conf.d/ssl.include
Include conf.d/ssl.include.star
### ^ these point to a file which specifies where the ssl certificates
### live on the host.

ProxyPass / http://127.0.0.1:8877/ retry=10 connectiontimeout=5
### ^ this tells httpd to redirect it's / to localhost port 8877
timeout=300
ProxyPassReverse / http://127.0.0.1:8877/ retry=10
### ^ this tells httpd that tomcat's url's should be rewritten to look
### like they're coming from httpd.
ProxyPreserveHost On
### ^ this tells httpd to keep the Host: information from the client and
### pass it on to tomcat.

</VirtualHost>




So much for the virtualhost/proxy setup.

To get httpd to use ssl, you will need to have mod_ssl installed, a
ssl.conf file telling httpd how to use ssl and include files(mentioned
above) with information about your certificates.



Here's our ssl.conf file:

Listen 443 https
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog
SSLSessionCache shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout 300
SSLRandomSeed startup file:/dev/urandom 256
SSLRandomSeed connect builtin
SSLCryptoDevice builtin
SSLStaplingCache shmcb:/run/httpd/ocsp(128000)
# The default 'combined' format extended with SSL protocol and cipher
logging
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"
\"%{SSL_PROTOCOL}x\" \"%{SSL_CIPHER}x\"" combinedssl



This is our ssl.include file:

SSLEngine on
# modern configuration, tweak to your needs
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLHonorCipherOrder on
SSLCompression off
# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off



And this is our ssl.include.star file:

SSLCertificateFile /etc/pki/tls/certs/star.mydomain.edu.crt
SSLCertificateChainFile /etc/pki/tls/certs/star.mydomain.edu.chain.crt
SSLCertificateKeyFile /etc/pki/tls/private/star.mydomain.edu.key






I hope this helps a bit. We're running CentOS so YMMV.

/tony


--
Tony Albers
Systems administrator, IT-development
Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: +45 2566 2383 / +45 8946 2316

[Dayne Ellanna]

Tony,

For the proxy, you are routing to 8877, in my case that would be 8443 correct?

Thanks,

Dayne

--
You received this message because you are subscribed to a topic in the Google Groups "DSpace Technical Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dspace-tech/6ZTVNgGfBcQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dspace-tech+unsubscribe@googlegroups.com.
To post to this group, send email to dspac...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[Mark H. Wood]

On Friday, October 6, 2017 at 2:39:34 AM UTC-4, Dayne Ellanna wrote:

I am having the worst time getting tomcat to do https for dspace.  I followed the instructions on the dspace site but cannot make heads or tails of the instructions as I am definitely not a certificate expert.  The instructions use generic names and don't explain where root ca's come from or generating certificate requests and from what do I generate these.  Can someone give me very specific instructions about how to set up the https on tomcat to run dspace.  So far I have gotten dspace to run successfully as http://myserver.domain:8080/xmlui.  As per instructions on the dspace site I have tried to create the RSA key, and we use incommon for our certs which I can obtain, but have not been able to figure out the beginning to end process for this.  I tried using curl to test but no success.  I really need a succinct explanation of all the pieces, where to get them or how to generate them in order to run the ssl.  HELP!

We also proxy through Apache HTTPD, via AJP, in part because setting up certificates for Tomcat is such a pain.

We are also an InCommon member so I can speak to that.  You'll need the "InCommon RSA Server CA" intermediate certificate.  On this Gentoo Linux system it's in '/etc/ssl/certs/InCommon-RSA-Server-CA.pem' and should be similarly named on yours.  It is signed by "USERTrust RSA Certification Authority", in USERTrust_RSA_Certification_Authority.crt or something similar, which is the root certificate.  You can see the gory details of certificates, including the CN (e.g. "InCommon RSA Server CA") with 'openssl x509 -noout -text -in /path/to/some/certificate.pem'.  (Sorry, I only use 'keytool' when I can't avoid it, and don't know by heart the options for this operation.)

It's impossible to write specific letter-for-letter instructions for this topic that cover all supported platforms, because they disagree as to where things like CATALINA_BASE and JAVA_HOME are.  If you'd tell us what OS, distribution and version you're using, that would help.  If you did *not* use your OS' package manager to install Tomcat, or Java, then it would help to tell us where you installed them.  In the meantime, you probably can forget about '$JAVA_HOME/bin' and assume that 'keytool' is available just like any other command.  If you search your system for 'server.xml' that should help you locate '$CATALINA_BASE/conf'.

I recommend inventing some keystore password other than "changeit", because everybody knows that's the default password and thus it is no security at all.

Whenever you have a question about Tomcat, it would be helpful to state the specific version that you are using.  When you have a question about DSpace (or its documentation), it would be helpful to state the specific version that you are using.

[Mark H. Wood]

Oh, drat, I forgot that the InCommon certificate wasn't in the OS' cert. bundle and I had to go get it from InCommon.  The email which told you where to download your certificate should also tell you where to get theirs.

[Tony Brian Albers]

On 10/06/2017 04:28 PM, Dayne Ellanna wrote:
> Tony,
>
> For the proxy, you are routing to 8877, in my case that would be 8443
> correct?
>
> Thanks,
> Dayne
>

Nope, you should point to whatever port your tomcat is running on, which
I suppose is http://myserver.domain:8080/xmlui -> 8080
Disregard that tomcat is not running https, that's what you're going to
use httpd(apache) for.

Sorry for the late reply, I was off on weekend when you wrote me back :)

/tony

> On Thu, Oct 5, 2017 at 10:39 PM, Dayne Ellanna <diel...@alaska.edu
> <mailto:diel...@alaska.edu>> wrote:
>
> I am having the worst time getting tomcat to do https for dspace.  I
> followed the instructions on the dspace site but cannot make heads
> or tails of the instructions as I am definitely not a certificate
> expert.  The instructions use generic names and don't explain where
> root ca's come from or generating certificate requests and from what
> do I generate these.  Can someone give me very specific instructions
> about how to set up the https on tomcat to run dspace.  So far I
> have gotten dspace to run successfully as
> http://myserver.domain:8080/xmlui

> <http://myserver.domain:8080/xmlui>.  As per instructions on the

> dspace site I have tried to create the RSA key, and we use incommon
> for our certs which I can obtain, but have not been able to figure
> out the beginning to end process for this.  I tried using curl to
> test but no success.  I really need a succinct explanation of all
> the pieces, where to get them or how to generate them in order to
> run the ssl.  HELP!
>
> Thanks,
> Dayne
>
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "DSpace Technical Support" group.
> To unsubscribe from this topic, visit

> https://groups.google.com/d/topic/dspace-tech/6ZTVNgGfBcQ/unsubscribe <https://groups.google.com/d/topic/dspace-tech/6ZTVNgGfBcQ/unsubscribe>.

> To unsubscribe from this group and all its topics, send an email to

> dspace-tech...@googlegroups.com
> <mailto:dspace-tech...@googlegroups.com>.

> To post to this group, send email to dspac...@googlegroups.com

> <mailto:dspac...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/dspace-tech

> <https://groups.google.com/group/dspace-tech>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google

> Groups "DSpace Technical Support" group.

> To unsubscribe from this group and stop receiving emails from it, send
> an email to dspace-tech...@googlegroups.com
> <mailto:dspace-tech...@googlegroups.com>.

> To post to this group, send email to dspac...@googlegroups.com

> <mailto:dspac...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.

[wlruth...@alaska.edu]

Hello Tony. I work with Dayne and we are successfully using a localized version
of your example at our site - Thank you. But there's one problem.

We are using port 443 for secure connections and securing the site by rewriting
port 80 to also go to port 443. The handle server uses ports 2641 and 8000 and
needs them to to be non-SSL. But something is converting our http://hdl.handle.net/
URI links to https. So, rather than linking to the document page, we get something
like this:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://scholarworks.alaska.edu/"><b>https://scholarworks.alaska.edu/</b></a></blockquote></p>
<hr>
<address>Apache/2.2.15 (Red Hat) Server at scholarworks.alaska.edu Port 443</address>
</body></html>

My best guess at the moment is that the virtualhost configurations are
also somehow catching other ports and rewriting them in the same way.

<VirtualHost *:80>
#
        ### Redirect insecure ports to secure port 443
        ServerAdmin uaf-libra...@alaska.edu
        RewriteEngine On
        RewriteCond %{HTTPS} off
#       RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]
        RewriteRule (.*) https://%{HTTP_HOST}:443%{REQUEST_URI}
        DocumentRoot /dspace/webapps/xmlui
        ServerName scholarworks.alaska.edu
        ServerAlias scholarworks

        ErrorLog logs/scholarworks.alaska.edu-error_log
        CustomLog logs/scholarworks.alaska.edu-access_log common

        ProxyPass / http://127.0.0.1:443/  retry=10 connectiontimeout=5
        ### ^ this tells httpd to redirect it's / to localhost port 443

        #timeout=300
        ProxyPassReverse / http://127.0.0.1:443/  retry=10

        ### ^ this tells httpd that tomcat's url's should be rewritten to look
        ###   like they're coming from httpd.

        ProxyPreserveHost On
        ### ^ this tells httpd to keep the Host: information from the client and
        ### pass it on to tomcat.

</VirtualHost>

#<VirtualHost scholarworks.alaska.edu:443>
<VirtualHost *:443>

        ### ^ this creates a httpd server that listens on port 443.

        ServerAdmin uaf-libra...@alaska.edu
        DocumentRoot /dspace/webapps/xmlui
        ServerName scholarworks.alaska.edu
        ServerAlias scholarworks

        ErrorLog logs/scholarworks.alaska.edu-https-error_log
        CustomLog logs/scholarworks.alaska.edu-https-access_log combinedssl

        Include conf.d/ssl.include
        Include conf.d/ssl.include.star
        ### ^ these point to a file which specifies where the ssl certificates
        ###   live on the host.

        ProxyPass /     http://127.0.0.1:8080/  retry=10 connectiontimeout=5
        ### ^ this tells httpd to redirect it's / to localhost port 8080

        #timeout=300

        ProxyPassReverse /      http://127.0.0.1:8080/  retry=10

        ### ^ this tells httpd that tomcat's url's should be rewritten to look
        ###   like they're coming from httpd.

        ProxyPreserveHost On
        ### ^ this tells httpd to keep the Host: information from the client and
        ### pass it on to tomcat.

        #SSLUseStapling on
        ### Added due to error when starting apache.  Dayne Ellanna

</VirtualHost>

We once were trying to do this via Tomcat rewriting 8080 to 443. But when
we gave up on Tomcat I disabled the unneeded ports 8080 and 8443. I also
changed the proxy references to 8080 in <virtualhost *:80> to 443; that won't
work in the <virtualhost *:443> section because it would reroute to itself.

So why do I need the 443 proxy directives at all? I tried commenting out the
entire line but that just breaks the whole site. The only place ports 2641 and
8000 are ever mentioned is in the handler-server/config.dct file.

{
"hdl_http_config" = {
"bind_address" = "137.229.115.121"
"num_threads" = "15"
"bind_port" = "8000"
"backlog" = "5"
"log_accesses" = "yes"
}

"server_type" = "server"
"hdl_udp_config" = {
"bind_address" = "137.229.115.121"
"num_threads" = "15"
"bind_port" = "2641"
"log_accesses" = "yes"
}

"hdl_tcp_config" = {
"bind_address" = "137.229.115.121"
"num_threads" = "15"
"bind_port" = "2641"
"backlog" = "5"
"log_accesses" = "yes"
}

"no_udp_resolution" = "n"
"interfaces" = (
"hdl_udp"
"hdl_tcp"
"hdl_http"
)

"server_config" = {
"server_admins" = (
"300:0.NA/11122"
)

"replication_admins" = (
"300:0.NA/11122"
)

"storage_type" = "CUSTOM"
"storage_class" = "org.dspace.handle.HandlePlugin"
"max_session_time" = "86400000"
"this_server_id" = "1"
"max_auth_time" = "60000"
"backup_admins" = (
"300:0.NA/11122"
)

"case_sensitive" = "no"
}

}


Does anyone see anything glaringly wrong with this setup?
I believe the local handle-server process passes the request
to handle.net just fine. But somewhere during the return trip
we're redirected to port 443 and things to south.

Thanks for any tips, insights, or corrections you can provide,

  Walter R.

[Mark H. Wood]

On Tuesday, October 24, 2017 at 9:46:58 PM UTC-4, wlruth...@alaska.edu wrote:

We are using port 443 for secure connections and securing the site by rewriting
port 80 to also go to port 443. The handle server uses ports 2641 and 8000 and
needs them to to be non-SSL. But something is converting our http://hdl.handle.net/
URI links to https. So, rather than linking to the document page, we get something
like this:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://scholarworks.alaska.edu/"><b>https://scholarworks.alaska.edu/</b></a></blockquote></p>
<hr>
<address>Apache/2.2.15 (Red Hat) Server at scholarworks.alaska.edu Port 443</address>
</body></html>

I tried following the URI: link at https://scholarworks.alaska.edu/xmlui/handle/11122/6433 using 'curl'.  The Handle link there is 'http://hdl.handle.net/11122/6433'.  hdl.handle.net responded with a 303 redirect to 'http://scholarworks.alaska.edu:443/xmlui/handle/11122/6433' which is wrong:  it should either use 'https:' or omit the port 443.  I suspect that you've set 'dspace.url' to 'http://scholarworks.alaska.edu:443' instead of 'https://scholarworks.alaska.edu:443'.  The DSpace Handle resolver just appends the object's handle to the value of 'dspace.url' and sends that back to the master resolver at hdl.net.

 

My best guess at the moment is that the virtualhost configurations are
also somehow catching other ports and rewriting them in the same way.

<VirtualHost *:80>
#
        ### Redirect insecure ports to secure port 443
        ServerAdmin uaf-libra...@alaska.edu
        RewriteEngine On
        RewriteCond %{HTTPS} off
#       RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]
        RewriteRule (.*) https://%{HTTP_HOST}:443%{REQUEST_URI}

This probably doesn't accomplish anything, since a rewrite to the same host will be stripped down to the localpart.  Forcing a redirect, as in the line above it, should evoke a new request to the proper port.  Try appending '[R,L]' or '[R=permanent,L]'.

 

        DocumentRoot /dspace/webapps/xmlui
        ServerName scholarworks.alaska.edu
        ServerAlias scholarworks

        ErrorLog logs/scholarworks.alaska.edu-error_log
        CustomLog logs/scholarworks.alaska.edu-access_log common

        ProxyPass / http://127.0.0.1:443/  retry=10 connectiontimeout=5
        ### ^ this tells httpd to redirect it's / to localhost port 443

No.  This is not a redirect.  HTTPD will act like a client and ask the target for the localpart, then send the reply back to *its* client.  Above HTTPD is proxying through itself, which is probably not what you want.  Here we have no proxy rules at all for port 80, only actual redirects telling HTTPD's client to try again on port 443.  All the proxying happens in the port 443 virtual host.  I would just take all this proxy stuff out of this vhost.

 

        #timeout=300
        ProxyPassReverse / http://127.0.0.1:443/  retry=10
        ### ^ this tells httpd that tomcat's url's should be rewritten to look
        ###   like they're coming from httpd.

        ProxyPreserveHost On
        ### ^ this tells httpd to keep the Host: information from the client and
        ### pass it on to tomcat.

</VirtualHost>

#<VirtualHost scholarworks.alaska.edu:443>
<VirtualHost *:443>

        ### ^ this creates a httpd server that listens on port 443.

        ServerAdmin uaf-libra...@alaska.edu
        DocumentRoot /dspace/webapps/xmlui
        ServerName scholarworks.alaska.edu
        ServerAlias scholarworks

        ErrorLog logs/scholarworks.alaska.edu-https-error_log
        CustomLog logs/scholarworks.alaska.edu-https-access_log combinedssl

        Include conf.d/ssl.include
        Include conf.d/ssl.include.star
        ### ^ these point to a file which specifies where the ssl certificates
        ###   live on the host.

        ProxyPass /     http://127.0.0.1:8080/  retry=10 connectiontimeout=5
        ### ^ this tells httpd to redirect it's / to localhost port 8080

Again, not a redirect; this causes HTTPD to send a request to whatever is on port 8080 (Tomcat, I presume) and forward its response back to HTTPD's client.  This is what you need in order to actually serve user requests.

 

        #timeout=300

        ProxyPassReverse /      http://127.0.0.1:8080/  retry=10
        ### ^ this tells httpd that tomcat's url's should be rewritten to look
        ###   like they're coming from httpd.

        ProxyPreserveHost On
        ### ^ this tells httpd to keep the Host: information from the client and
        ### pass it on to tomcat.

        #SSLUseStapling on
        ### Added due to error when starting apache.  Dayne Ellanna

</VirtualHost>

We once were trying to do this via Tomcat rewriting 8080 to 443. But when
we gave up on Tomcat I disabled the unneeded ports 8080 and 8443. I also
changed the proxy references to 8080 in <virtualhost *:80> to 443; that won't
work in the <virtualhost *:443> section because it would reroute to itself.

So why do I need the 443 proxy directives at all? I tried commenting out the
entire line but that just breaks the whole site.

Does anyone see anything glaringly wrong with this setup?
I believe the local handle-server process passes the request
to handle.net just fine. But somewhere during the return trip
we're redirected to port 443 and things to south.

The local handle resolver does not pass requests to handle.net; it receives resolution requests from handle.net and returns corresponding URLs.  I think that calculating the "corresponding URL" is where the scheme/port mismatch happens.  See above.

[wlruth...@alaska.edu]

On Wednesday, October 25, 2017 at 8:56:57 AM UTC-8, Mark H. Wood wrote:

On Tuesday, October 24, 2017 at 9:46:58 PM UTC-4, wlruth...@alaska.edu wrote:

We are using port 443 for secure connections and securing the site by rewriting
port 80 to also go to port 443. The handle server uses ports 2641 and 8000 and
needs them to to be non-SSL. But something is converting our http://hdl.handle.net/
URI links to https. So, rather than linking to the document page, we get something
like this:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://scholarworks.alaska.edu/"><b>https://scholarworks.alaska.edu/</b></a></blockquote></p>
<hr>
<address>Apache/2.2.15 (Red Hat) Server at scholarworks.alaska.edu Port 443</address>
</body></html>

I tried following the URI: link at https://scholarworks.alaska.edu/xmlui/handle/11122/6433 using 'curl'.  The Handle link there is 'http://hdl.handle.net/11122/6433'.  hdl.handle.net responded with a 303 redirect to 'http://scholarworks.alaska.edu:443/xmlui/handle/11122/6433' which is wrong:  it should either use 'https:' or omit the port 443.  I suspect that you've set 'dspace.url' to 'http://scholarworks.alaska.edu:443' instead of 'https://scholarworks.alaska.edu:443'.  The DSpace Handle resolver just appends the object's handle to the value of 'dspace.url' and sends that back to the master resolver at hdl.net.

 

 You're right, there was a mismatch in the dspace.cfg file between http:// and the secure port 443. Unfortunately, changing dspace.url to clean https:// didn't fix the problem. Same error.

 

My best guess at the moment is that the virtualhost configurations are
also somehow catching other ports and rewriting them in the same way.

<VirtualHost *:80>
#
        ### Redirect insecure ports to secure port 443
        ServerAdmin uaf-libra...@alaska.edu
        RewriteEngine On
        RewriteCond %{HTTPS} off
#       RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]
        RewriteRule (.*) https://%{HTTP_HOST}:443%{REQUEST_URI}

This probably doesn't accomplish anything, since a rewrite to the same host will be stripped down to the localpart.  Forcing a redirect, as in the line above it, should evoke a new request to the proper port.  Try appending '[R,L]' or '[R=permanent,L]'.

 

        DocumentRoot /dspace/webapps/xmlui
        ServerName scholarworks.alaska.edu
        ServerAlias scholarworks

        ErrorLog logs/scholarworks.alaska.edu-error_log
        CustomLog logs/scholarworks.alaska.edu-access_log common

        ProxyPass / http://127.0.0.1:443/  retry=10 connectiontimeout=5
        ### ^ this tells httpd to redirect it's / to localhost port 443

No.  This is not a redirect.  HTTPD will act like a client and ask the target for the localpart, then send the reply back to *its* client.  Above HTTPD is proxying through itself, which is probably not what you want.  Here we have no proxy rules at all for port 80, only actual redirects telling HTTPD's client to try again on port 443.  All the proxying happens in the port 443 virtual host.  I would just take all this proxy stuff out of this vhost.

I commented out the proxyPass lines for <virtualhost *:80> without breaking anything. I also added the "[R,L]" per your suggestion. So far I've noticed no difference.

 

 

        #timeout=300
        ProxyPassReverse / http://127.0.0.1:443/  retry=10
        ### ^ this tells httpd that tomcat's url's should be rewritten to look
        ###   like they're coming from httpd.

        ProxyPreserveHost On
        ### ^ this tells httpd to keep the Host: information from the client and
        ### pass it on to tomcat.

</VirtualHost>

#<VirtualHost scholarworks.alaska.edu:443>
<VirtualHost *:443>

        ### ^ this creates a httpd server that listens on port 443.

        ServerAdmin uaf-libra...@alaska.edu
        DocumentRoot /dspace/webapps/xmlui
        ServerName scholarworks.alaska.edu
        ServerAlias scholarworks

        ErrorLog logs/scholarworks.alaska.edu-https-error_log
        CustomLog logs/scholarworks.alaska.edu-https-access_log combinedssl

        Include conf.d/ssl.include
        Include conf.d/ssl.include.star
        ### ^ these point to a file which specifies where the ssl certificates
        ###   live on the host.

        ProxyPass /     http://127.0.0.1:8080/  retry=10 connectiontimeout=5
        ### ^ this tells httpd to redirect it's / to localhost port 8080

Again, not a redirect; this causes HTTPD to send a request to whatever is on port 8080 (Tomcat, I presume) and forward its response back to HTTPD's client.  This is what you need in order to actually serve user requests.

 

 

Network port 8080 is closed. But our site displays a generic default page if the following isn't configured in server.xml (with or without the proxy definitions in vhosts.conf):

    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="443" />

I did a recursive search and see that port 8080 is configured into several modules so I might not be able to get rid of it without rebuilding Tomcat from scratch. But I don't believe the actual network port is necessary so I'll leave the external network port 8080 closed.

So I'm not sure what the proxyPass is doing for <virtualhost *:443>. It seems to be redirecting to port 8080 which redirects to 443. Together it looks circular to me but the site breaks if I remove either the Connector redirection or the proxy redirection, or both.

[wlruth...@alaska.edu]

I may have it fixed but to do it I had to ignore the handle setup instructions and use
port 443 instead of port 8000. That forces a secure reference. Nothing appears to
happen when I click on the URI. Since http://hdl.handle.net/11122/<RefNum> points
right back to the same page containing the link that makes perfect sense.