Re: Using sec-activate to enable SSL for admin server

[Grant Byers <Grant.Byers@xxxxxxxxxxxxx>]

Thanks Viktor. That’s a nice script. FWIW, I’ve solved this through a simple HTTP POST in Ansible;

 

    - name: enable SSL for admin server

      uri:

        url: "http://127.0.0.1:{{ dirsrv_port_admin }}/admin-serv/tasks/configuration/SSLActivate"

        method: POST

        url_username: "{{ dirsrv_rootdn }}

        url_password: "{{ dirsrv_rootpw }}"

        body_format: 'form-urlencoded'

        body:

          'security': 'on'

          'familyList': 'RSA'

          'RSA-activated': 'on'

          'RSA-token': 'internal (software)'

          'RSA-cert': 'server-cert'

          'ssl2-activated': 'off'

          'ssl3-activated': 'on'

          'clientauth': 'off'

          'ssl2': '-des,-rc2export,-rc4export,-desede3,-rc4,-rc2'

          'ssl3': '-rsa_rc2_40_md5,-rsa_rc4_128_md5,-rsa_3des_sha,-rsa_rc4_40_md5,-rsa_null_sha,-fips_des_sha,-fips_3des_sha,-rsa_des_sha,-rsa_null_md5,+rsa_aes_128_sha,+rsa_aes_256_sha,-rsa_des_56_sha,-rsa_rc4_56_sha'

        timeout: 120

      tags:

        - ldapds_admin_ssl

      notify: restart admin server

 

This worked very well for me and I’m happy with the solution.

 

Cheers

Grant

 

From: Viktor Ashirov <vashirov@xxxxxxxxxx>
Sent: Friday, 8 November 2019 12:18 AM
To: General discussion list for the 389 Directory server project. <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: [389-users] Re: Using sec-activate to enable SSL for admin server

 

Hi Grant,

 

On Thu, Nov 7, 2019 at 2:16 AM Grant Byers <Grant.Byers@xxxxxxxxxxxxx> wrote:

Hi Mark,

 

I am using certutil and a pin file, but that’s only half of what’s required. The other half involves adding and/or amending entries in the local and adm bootstrap configs, in the global config database (o=NetscapeRoot), and some apache config. The latter tasks are simplified by using the console to enable SSL for the admin server (which does so by calling the sec-activate cgi), but that is a manual step and doesn’t lend itself well to automation. I have played a little with hand editing these files with success, which I can automate, but it’s fickle. Any upstream change could potentially break that, whereas calling the tool used by the admin server to configure itself would be a more robust approach (IMO).

 

The official documentation only has the manual approach via the console. No good for automation.

Please check this script:

https://raw.githubusercontent.com/richm/scripts/master/setupssl2.sh 

 

Run it as 

# ./setupssl2.ssh /etc/dirsrv/slapd-INSTANCE

 

HTH

 

Grant

 

From: Mark Reynolds <mreynolds@xxxxxxxxxx>
Sent: Thursday, 7 November 2019 12:24 AM
To: General discussion list for the 389 Directory server project. <389-users@xxxxxxxxxxxxxxxxxxxxxxx>; Grant Byers <Grant.Byers@xxxxxxxxxxxxx>
Subject: Re: [389-users] Using sec-activate to enable SSL for admin server

 

 

On 11/6/19 12:42 AM, Grant Byers wrote:

Hi,

 

I’ve mostly completed automated deployment of a 389ds cluster via Ansible. The final piece of the puzzle is the enablement of SSL/TLS for the Admin server.  From what I understand, I should be able to use the sec-activate tool to do this;

 

/usr/lib64/dirsrv/cgi-bin/sec-activate /etc/dirsrv/admin-serv on

 

What I can’t figure out is how to authenticate. When I run this, it prompts me repeatedly for Ënter Admin Server Administrator password:”. I have tried both the RootDN and ConfigDirectoryAdminPwd passwords, but neither seem to work.

 

Can anyone suggest what’s going on here & how I might get past it?

 

 

I have never used, or heard of anyone using, sec-activate to enable SSL in the admin server.  I suggest following the official documentation on setting this up using certutil and a password/pin file:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/enabling_tls#enabling_tls_in_the_administration_server

HTH,

Mark

 

 

Thanks,

Grant

 

_______________________________________________

389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx

To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx

Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx

-- 

389 Directory Server Development Team

_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx

 

--

Viktor

_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx