[JIRA] Commented: (SIDP-521) Allow specificying file location of renewed key and certificate

[Lukas Haemmerle (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/SIDP-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13672#comment-13672 ] 

Lukas Haemmerle commented on SIDP-521:
--------------------------------------

The message "... overwriting existing credentials. Do you really wish to proceed?" on line 206 might not be correct/needed anymore. Unless of course somebody has renewed their cert/key pair already once before.

> Allow specificying file location of renewed key and certificate
> ---------------------------------------------------------------
>
>                 Key: SIDP-521
>                 URL: https://issues.shibboleth.net/jira/browse/SIDP-521
>             Project: Shibboleth IdP 2 - Java
>          Issue Type: Improvement
>            Reporter: Lukas Haemmerle
>            Assignee: Chad La Joie
>            Priority: Minor
>             Fix For: 2.3.4
>
>
> As is written on: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPCertRenew an IdP admin can renew the self-signed certification using the following commands: 
> {code} 
> export IdPCertLifetime=3
> ./install.sh renew-cert
> {code} 
> This is very useful and helpful :-) One thing that could be improved:
> The build.xml assumes that the key and certifcate are always called idp.{crt,key,jks} and are stored in /opt/shibboleth-idp/credentials. And it overwrites the current key and certificate.
> While this is fine in most cases, it is dangerous in others. The new certificate has first to be included in (federation) metadata before it can be actively used by the IdP. However, metadata propagation takes some time. In some cases more than a day. If during this time the IdP is restarted (automatically or acceidentally), the new key/certificate might be used before all relying-parties know about the new one.
> Therefore, the proposal is to optionally allow an admin to specify the location of the new certificate and key so that the current one is not overwritten. It should also be taken care of the file permissions of the new key (they should be the same as for the current certificate). Alternatively an option to not overwrite the existing key/cert but instead create the key/cert with different filenames (for instance idp.key.new idp.crt.new) could be used.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira