Re: [dspace-tech] Tomcat Cert Process for Dspace

2017-10-25 Thread wlrutherford 

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/ 
points
right back to the same page containing the link that makes perfect sense.


On Wednesday, October 25, 2017 at 1:11:49 PM UTC-8, wlruth...@alaska.edu 
wrote:
>
>
>
> 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:
>>>
>>> 
>>> 
>>> 400 Bad Request
>>> 
>>> Bad Request
>>> Your browser sent a request that this server could not understand.
>>> Reason: You're speaking plain HTTP to an SSL-enabled server port.
>>> Instead use the HTTPS scheme to access this URL, please.
>>> Hint: https://scholarworks.alaska.edu/ 
>>> ">https://scholarworks.alaska.edu/
>>> 
>>> Apache/2.2.15 (Red Hat) Server at scholarworks.alaska.edu Port 
>>> 443
>>> 
>>>
>>>
>>>
>>
>> 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.
>>>
>>> 
>>> #
>>> ### 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  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.
>>>
>>> 
>>>
>>> #
>>> 
>>>
>>> ### ^ 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

Re: [dspace-tech] Tomcat Cert Process for Dspace

2017-10-25 Thread wlrutherford 


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:
>>
>> 
>> 
>> 400 Bad Request
>> 
>> Bad Request
>> Your browser sent a request that this server could not understand.
>> Reason: You're speaking plain HTTP to an SSL-enabled server port.
>> Instead use the HTTPS scheme to access this URL, please.
>> Hint: https://scholarworks.alaska.edu/ 
>> ">https://scholarworks.alaska.edu/
>> 
>> Apache/2.2.15 (Red Hat) Server at scholarworks.alaska.edu Port 
>> 443
>> 
>>
>>
>>
>
> 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.
>>
>> 
>> #
>> ### 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  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.
>>
>> 
>>
>> #
>> 
>>
>> ### ^ 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)

Re: [dspace-tech] Tomcat Cert Process for Dspace

2017-10-25 Thread Mark H. Wood 
On Tuesday, October 24, 2017 at 9:46:58 PM UTC-4, wlrutherf...@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:
>
> 
> 
> 400 Bad Request
> 
> Bad Request
> Your browser sent a request that this server could not understand.
> Reason: You're speaking plain HTTP to an SSL-enabled server port.
> Instead use the HTTPS scheme to access this URL, please.
> Hint: https://scholarworks.alaska.edu/ 
> ">https://scholarworks.alaska.edu/
> 
> Apache/2.2.15 (Red Hat) Server at scholarworks.alaska.edu Port 
> 443
> 
>
>
>

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.
>
> 
> #
> ### Redirect insecure ports to secure port 443
> ServerAdmin uaf-library-it-d...@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.
>
> 
>
> #
> 
>
> ### ^ this creates a httpd server that listens on port 443.
>
> ServerAdmin uaf-library-it-d...@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

Re: [dspace-tech] Tomcat Cert Process for Dspace

2017-10-24 Thread wlrutherford 
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:



400 Bad Request

Bad Request
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
Hint: https://scholarworks.alaska.edu/;>https://scholarworks.alaska.edu/

Apache/2.2.15 (Red Hat) Server at scholarworks.alaska.edu Port 
443



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


#
### Redirect insecure ports to secure port 443
ServerAdmin uaf-library-it-d...@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.



#


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

ServerAdmin uaf-library-it-d...@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



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  to 443; that 
won't
work in the  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" = "8640"
"this_server_id" = "1"
"max_auth_time" = "6"
"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.



On Friday, October 6, 2017 at 1:28:00 AM UTC-8, Tony Brian Albers wrote:
>
> On 10/06/2017 08:39 AM, Dayne Ellanna wrote: 
> > I am having the

Re: [dspace-tech] Tomcat Cert Process for Dspace

2017-10-08 Thread 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  > 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!
> 
> 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+unsubscr...@googlegroups.com
> .
> To post to this group, send email to dspace-tech@googlegroups.com
> .
> Visit this group at https://groups.google.com/group/dspace-tech
> .
> For more options, visit 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+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to dspace-tech@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.


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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Tomcat Cert Process for Dspace

2017-10-06 Thread Dayne Ellanna 
Tony,

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

Thanks,
Dayne

On Thu, Oct 5, 2017 at 10:39 PM, 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!
>
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to dspace-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit 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+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Tomcat Cert Process for Dspace

2017-10-06 Thread Tony Brian Albers 
On 10/06/2017 08:39 AM, 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!
> 
> Thanks,
> Dayne
> 

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

### ^ this creates a httpd server listening on port 80.
ServerAdmin helpd...@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.




### ^ this creates a httpd server that listens on port 443.
ServerAdmin helpd...@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.






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
SSLStaplingCacheshmcb:/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,

[dspace-tech] Tomcat Cert Process for Dspace

2017-10-06 Thread 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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.