Trying to renew a certificate - nss error 8168
by rainer＠ultra-secure.de
Hi,
I'm trying to renew a certificate in 389 server.
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
I've created a new private key and CSR with
certutil -d /etc/dirsrv/slapd-instance/ -R -g 4096 -a \
-o /root/slapd-name.csr -8 name.fqdn \
-s "CN=name.fqdn,O=org,ST=State,C=CH"
I try to import it with
certutil -d /etc/dirsrv/slapd-instance/ -A \
-n "Server Cert" -t ",," -a -i /root/slapd-name.crt
But this results in
"certutil: could not add certificate to token or database:
SEC_ERROR_ADDING_CERT: Error adding certificate to database."
If I try this using the GUI, I also get the NSS error code 8168
What exactly is the problem?
It seems there is no "verbose" switch for certutil - or at least it's
not documented.
389-admin-1.1.46-1.el7.x86_64
389-admin-console-1.1.12-1.el7.noarch
389-admin-console-doc-1.1.12-1.el7.noarch
389-adminutil-1.1.22-2.el7.x86_64
389-console-1.1.19-6.el7.noarch
389-ds-base-1.3.10.1-9.el7_8.x86_64
389-ds-base-libs-1.3.10.1-9.el7_8.x86_64
389-ds-base-snmp-1.3.10.1-9.el7_8.x86_64
389-ds-console-1.2.16-1.el7.noarch
389-ds-console-doc-1.2.16-1.el7.noarch
CentOS 7, 64bit.
Now, I tried to list the private keys with -K, I get
certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The
certificate/key database is in an old, unsupported format.
Is there documentation on how to upgrade the database?
Rainer
3 years, 7 months
How to disable attribute encryption
by Jan Tomasek
Hello,
is it possible to disable attribute encryption in 389 DS? I'm running
1.4.0.21 @ Debian Buster.
After replacing TLS certificate I'm receiving errors:
> [18/Aug/2020:10:25:16.099482453 +0200] - ERR - attrcrypt_unwrap_key - Failed to unwrap key for cipher 3DES
> [18/Aug/2020:10:25:16.099670006 +0200] - ERR - attrcrypt_cipher_init - Symmetric key failed to unwrap with the private key; Cert might have been renewed since the key is wrapped. To recover the encrypted contents, keep the wrapped symmetric key value.
I found:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
But, I do not use any encrypted attribute so dumping and restoring
database is not nice way how to deal witch such error.
Just, deleting all keys and server restart works too:
ldapsearch -H ldap://localhost -D "cn=Directory Manager" -W -LLL -o
ldif-wrap=no -b "cn=ldbm database,cn=plugins,cn=config"
"(nsSymmetricKey=*)" dn | sed "s/^$/changetype: delete\n/" | ldapmodify
-H ldap://localhost -D "cn=Directory Manager" -W
Enter LDAP Password: Enter LDAP Password:
***
deleting entry "cn=3DES,cn=encrypted attribute keys,cn=xxx,cn=ldbm
database,cn=plugins,cn=config"
deleting entry "cn=AES,cn=encrypted attribute keys,cn=xxx,cn=ldbm
database,cn=plugins,cn=config"
deleting entry "cn=3DES,cn=encrypted attribute keys,xxx,cn=ldbm
database,cn=plugins,cn=config"
deleting entry "cn=AES,cn=encrypted attribute keys,xxx,cn=ldbm
database,cn=plugins,cn=config"
...
The best option would be config option to disable attribute encryption
for all databases but I failed to find if it is possible.
Thanks
--
-----------------------
Jan Tomasek aka Semik
http://www.tomasek.cz/
3 years, 8 months
CPU Scalability / Scaling
by Ben Spencer
After a little investigation I didn't find any recent information on how
well / linearly 389 scales from a CPU perspective. I also realize this is a
more complicated topic with many factors which actually play into it.
Throwing the basic question out there: Does 389 scale fairly linearly as
the number of CPUs are increased? Is there a point where it drops off?
Where am I going with this?
We are faced with either adding more CPUs to the existing servers or adding
more instances or a combination of the two. The current servers have 10 CPU
with the entire database fitting in RAM but, there is a regular flow of
writes. Sometimes somewhat heavy thanks to batch updates. Gut feeling
tells me to have more servers than a few huge servers largely because of
the writes/updates and lock contention. Needing to balance the server
sprawl as well.
Thank you for your insight -
Ben
3 years, 8 months
389 Admin Server 1.1.46 / SLE12 SP3 / Update mozilla-nss 3.47 -> 3.53.1
by essen.ids
Hi.
We are using the 389-ds version 1.4.2.15 with the 389 Admin Server 1.1.46
SLE12 has been updated and new Mozilla-nss packages in version 3.53.1 have
been installed.
Since then the communication between the admin server and the directory
server via ldaps no longer works.
The following message appears:
mod_admserv/mod_admserv.c(2372): Entering do_admserv_post_config - pid is
[15085]
mod_admserv/mod_admserv.c(2380): Entering do_admserv_post_config - init
count is [2]
mod_admserv/mod_admserv.c(2403): [15085] Cache expiration set to 600
seconds
sslinit: NSS is required to use LDAPS, but security initialization failed
[-8018:Unknown PKCS #11 error.]
When I downgrade the libsoftokn3 and libfreebl3 packages back to 3.47.1
the error message disappears. But the Connection does not work either.
I have now seen that since version 3.52.1 Mozilla-NSS PKCS #11 V3.0 is
supported and extensive changes have been made to the API.
Can anyone help me in this matter or do you know whom I could turn to?
With kind regards,
Petros Stavrakakis
____________________________________________________________________
Essen.IDs
B&R Industrial Automation GmbH | An der Reichsbank 8 | 45127 Essen |
Germany
T +49 201 74777 | F +49 201 74777
E essen.ids(a)br-automation.com | www.br-automation.com
B&R Industrial Automation GmbH | B&R Straße 1 | 5142 Eggelsberg | Austria
Court Registration No.: 111651 v | Ried im Innkreis | DVR No.: 0721301
FOLLOW US LinkedIn | YouTube | Twitter
3 years, 8 months
MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser
Hi,
I'm new to 389-ds and last week downloaded and installed the software.
I have a running instance of the server, and I've added TLS/SSL. I've configured a CentOS 7 client to be able to query
the server using TLS/SSL, and all appears working.
I've created users and groups on the 389-ds server successfully. For each user and group, I've enabled posix attributes and my client
can see the unix users and groups using the "getent password" or "getent group" commands.
Now, here's where I'm getting tripped up..........
I need to limit which users have access to which systems. I've been trying to do this via memberOf group limitations.
I found the following online resource (https://thornelabs.net/2013/01/28/aix-restrict-server-login-via-ldap-grou...)
which is close enough to CentOS that the initial commands worked.
I enabled the MemberOf plugin and changed the attributes per the link, and restarted the system.
I created a test group (that I didn't enable a posix GID) and tried to add a single user via:
Right click on group -- > click Properties --> then Members --> click Add --> Search for user --> click Add.
When I try to go this route (which worked before enabling the memberOf plugin) it worked. Now it seems I get the error:
"Cannot save to directory server.
netscape.ldap.LDAPException: error resiult(65): Object class violation"
And the messages file throws the error (/var/log/dirsrv/slapd-<instancename>/errors:
"Entry "uid=test,ou=People,dc=int,dc=com" -- attribute "memberOf" not allowed
[17/Feb/2016:11:22:58 -0700] memberof-plugin - memberof_postop_modify: failed to add dn (cn=testgroup,ou=Groups,dc=int,dc=com) to target. Error (65)"
So it seems my server isn't quite using the memberOf plugin properly, but I'm not sure what else to enable. I'll have to solve this issue before
I even try to filter login access via groups on my client system.
I should mention that if I go under the advanced tab for one of the groups I created, I can add the the attribute "uniquemember", but I'm not sure what I
should set the "value" to be.
I've tried creating new users to see if I could set their "uniquemember" attributes, but no luck. It seems that I don't have the ability to set this attribute
on individual users, only groups.
This might not be the right road to head down when trying to restrict access to servers via groups, so I'm open to any suggestions.
Any suggestions would be appreciated.
3 years, 8 months
