[Issue 10020] New: dynlist's @groupOfUniqueNames is considered only for the first configuration line
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=10020
Issue ID: 10020
Summary: dynlist's @groupOfUniqueNames is considered only for
the first configuration line
Product: OpenLDAP
Version: 2.5.13
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: msl(a)touk.pl
Target Milestone: ---
If we consider the following configuration of dynlist:
{0}toukPerson labeledURI uniqueMember+memberOf@groupOfUniqueNames
{1}groupOfURLs memberURL uniqueMember+dgMemberOf@groupOfUniqueNames
The {0} entry will correctly populate the memberOf relatively to static group
membership.
The {1} entry will produce dgMemberOf with dynamic group membership correctly
(based on memberURL query) but it will not populate static entries IF {0} entry
in configuration is present. IF I remove {0} from the dynlist configuration -
or - remove @groupOfUniqueNames part from this configuration line, then both
dynamic and static entries will be populated correctly for {1}.
So the effects are as follows on some user entry:
if both {0} and {1} are present - {1} produced only dynamic groups:
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
if both {0} and {1} are present and @groupOfUniqueNames is removed from {0} -
{1} produced static+dynamic groups:
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
If only {1} is present - {1} produced static+dynamic groups:
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
For completness - if only {0} is present:
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
I would expect this behavior to be correct for the first case - {0} and {1}.
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
--
You are receiving this mail because:
You are on the CC list for the issue.
4 months
[Issue 9934] New: slapd-config(5) should document how to store certificates for slapd usage
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9934
Issue ID: 9934
Summary: slapd-config(5) should document how to store
certificates for slapd usage
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Commit 7b41feed83b expanded the ability of cn=config to save the certificates
used for TLS by slapd directly in the config database. However the
documentation for the new parameters was never added to the slapd-config(5) man
page.
olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey
--
You are receiving this mail because:
You are on the CC list for the issue.
4 months
[Issue 9993] New: Potential race condition in back-mdb online indexer
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9993
Issue ID: 9993
Summary: Potential race condition in back-mdb online indexer
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
When the online indexer completes, it should mutex-protect its resetting of the
indexing flags.
--
You are receiving this mail because:
You are on the CC list for the issue.
4 months, 3 weeks
[Issue 10031] New: Conversion of slapd.conf fails using pcache
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=10031
Issue ID: 10031
Summary: Conversion of slapd.conf fails using pcache
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: stefan(a)kania-online.de
Target Milestone: ---
I've got the following working slapd.conf:
--------------------
include /opt/symas/etc/openldap/schema/core.schema
include /opt/symas/etc/openldap/schema/cosine.schema
include /opt/symas/etc/openldap/schema/inetorgperson.schema
include /opt/symas/etc/openldap/schema/misc.schema
include /opt/symas/etc/openldap/schema/nis.schema
include /opt/symas/etc/openldap/schema/msuser.schema
modulepath /opt/symas/lib/openldap
moduleload back_ldap
moduleload back_mdb
moduleload rwm.la
moduleload memberof.la
moduleload pcache.la
loglevel any
pidfile /var/symas/run/slapd.pid
argsfile /var/symas/run/slapd.args
database ldap
readonly yes
protocol-version 3
rebind-as-user yes
uri "ldap://192.168.56.201:389"
suffix "dc=example1,dc=net"
rootdn "cn=admin,dc=example1,dc=net"
idassert-bind bindmethod=simple
mode=none
binddn="CN=Administrator,cn=users,dc=example1,dc=net"
credentials=Passw0rd
tls_cacertdir=/opt/symas/etc/openldap
tls_reqcert=never
idassert-authzFrom "*"
overlay rwm
rwm-map attribute uid sAMAccountName
rwm-map objectClass posixAccount person
overlay memberof
memberof-group-oc groupOfuniqueNames
memberof-member-ad uniquemember
memberof-dangling error
overlay pcache
pcache mdb 100000 6 1000 100
pcachePersist TRUE
directory "/var/symas/pcache"
pcacheAttrset 0 1.1
pcacheTemplate (uid=) 0 3600
pcacheTemplate (&(|(objectClass=))) 0 3600
pcacheAttrset 1 employeetype givenName cn sn uid mail
pcacheTemplate (uid=) 1 3600
pcacheBind (uid=) 1 3600 sub dc=de
pcacheAttrset 2 givenName cn sn uid mail uidNumber
pcacheTemplate (objectClass=) 2 3600
pcacheAttrset 3 userPassword
pcacheTemplate (uid=) 3 3600
pcacheTemplate (objectClass=) 2 3600
pcacheAttrset 4 employeetype givenName cn sn uid mail
pcacheTemplate (uid=) 1 3600
pcacheAttrset 5 memberOf
pcacheTemplate (objectClass=*) 2 3600
--------------------
Search for an entry in AD is working:
----------------------
root@ldap-proxy01:~/server-setup/proxy# ldapsearch -x -b dc=example1,dc=net
cn=administrator -LLL dn
dn: cn=Administrator,cn=Users,dc=example1,dc=net
----------------------
Now I want convert it to cn=config but I'm getting the following error:
--------------------
root@ldap-proxy01:/opt/symas/etc/openldap# slaptest -F ./my-slapd.d/ -f
slapd.conf
Entry (olcDatabase={0}mdb,olcOverlay={2}pcache,olcDatabase={1}ldap,cn=config):
object class 'olcMdbBkConfig' requires attribute 'olcBackend'
config_build_entry: build "olcDatabase={0}mdb" failed: "(null)"
config file testing succeeded
mdb_opinfo_get: err Permission denied(13)
--------------------
When I comment out all the settings for the overlay pcache, converting
slapd.conf is working, but starting slapd gives me the following error:
--------------
Mär 27 20:02:03 ldap-proxy01 slapd[2042]: olcAttributeTypes: value #741
olcAttributeTypes: Duplicate attributeType: ""
Mär 27 20:02:03 ldap-proxy01 slapd[2042]: config error processing
cn={5}msuser,cn=schema,cn=config: olcAttributeTypes: Duplicate attributeType:
""
Mär 27 20:02:03 ldap-proxy01 slapd[2042]: send_ldap_result: conn=-1 op=0 p=0
Mär 27 20:02:03 ldap-proxy01 slapd[2042]: send_ldap_result: err=80 matched=""
text=""
--------------
slapcat -n0 tells me:
--------------
root@ldap-proxy01:/opt/symas/etc/openldap# slapcat -n0
olcAttributeTypes: value #741 olcAttributeTypes: Duplicate attributeType:
"�p�:V"
config error processing cn={5}msuser,cn=schema,cn=config: olcAttributeTypes:
Duplicate attributeType: "�p�:V"
slapcat: bad configuration file!
--------------
But switching back to slapd.conf the msuser.schema makes no problems.
Creating my own LDIF (without converting):
--------------------------
dn: cn=config
objectClass: olcGlobal
cn: config
olcLogLevel: any
olcPidFile: /var/symas/run/slapd.pid
olcArgsFile: /var/symas/run/slapd.args
olcToolThreads: 1
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /opt/symas/lib/openldap
olcModuleLoad: back_mdb
olcModuleLoad: back_ldap
olcModuleLoad: back_monitor
olcModuleLoad: argon2
include: file:///opt/symas/etc/openldap/schema/core.ldif
include: file:///opt/symas/etc/openldap/schema/cosine.ldif
include: file:///opt/symas/etc/openldap/schema/nis.ldif
include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif
include: file:///opt/symas/etc/openldap/schema/msuser.ldif
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcSizeLimit: 500
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
by * break
olcAccess: {1}to dn="" by * read
olcAccess: {2}to dn.base="cn=subschema" by * read
passwordHash: {ARGON2}
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=admin,cn=config
olcRootPW:
{ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4
olcAccess: {0}to *
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
dn: olcDatabase={1}monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {1}monitor
olcAccess: {0}to dn.subtree="cn=monitor"
by dn.exact=cn=admin,cn=config read
by dn.exact=cn=admin,dc=example,dc=net read
by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth read
dn: olcDatabase={2}ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {2}ldap
olcSuffix: dc=example1,dc=net
olcAddContentAcl: FALSE
olcLastMod: FALSE
olcLastBind: FALSE
olcLastBindPrecision: 0
olcMaxDerefDepth: 15
olcReadOnly: TRUE
olcRootDN: cn=admin,dc=example1,dc=net
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
olcDbURI: "ldap://dc-net01.example.net:389"
olcDbStartTLS: none starttls=no
olcDbIDAssertBind: mode=none flags=prescriptive,proxy-authz-non-critical bindm
ethod=simple timeout=0 network-timeout=0 binddn="cn=administrator,cn=users,dc
=example1,dc=net" credentials="Passw0rd" keepalive=0:0:0 tcp-user-timeout=0 t
ls_cacertdir="/opt/symas/etc/openldap" tls_reqcert=never tls_reqsan=allow tls
_crlcheck=none
olcDbIDAssertAuthzFrom: *
olcDbRebindAsUser: TRUE
olcDbChaseReferrals: FALSE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
--------------------------
msuser is working, no error about duplicate attributeType.
System ist Debian 11 with symas-packages OpenLDAP 2.6
--
You are receiving this mail because:
You are on the CC list for the issue.
4 months, 3 weeks
[Issue 10015] New: Config File KEEPALIVE_IDLE KEEPALIVE_PROBES KEEPALIVE_INTERVAL parser does random memory write
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=10015
Issue ID: 10015
Summary: Config File KEEPALIVE_IDLE KEEPALIVE_PROBES
KEEPALIVE_INTERVAL parser does random memory write
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: sean(a)teletech.com.au
Target Milestone: ---
In openldap/libraries/libldap/init.c: [master branch]
The Config File integers
KEEPALIVE_IDLE
KEEPALIVE_PROBES
KEEPALIVE_INTERVAL
Should be struct ol_attribute.type ATTR_OPT_INT rather than ATTR_INT.
ATTR_INT interprets struct ol_attribute.offset as a pointer to integer.
ATTR_OPT_INT interprets struct ol_attribute.offset as an option number to be
passed to ldap_set_option()
--
You are receiving this mail because:
You are on the CC list for the issue.
4 months, 3 weeks
[Issue 10016] New: syncprov may abandon a psearch improperly
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=10016
Issue ID: 10016
Summary: syncprov may abandon a psearch improperly
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
When processing an Abandon, it may remove the detached search op from the
connection while the qtask is actively sending search responses on the
connection. If the Abandon is due to an Unbind or connection loss, the
connection structure may get reused by a new conn while the qtask is still
running.
--
You are receiving this mail because:
You are on the CC list for the issue.
4 months, 3 weeks
[Issue 9953] New: Push replication issue for the pwdHistory attribute
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9953
Issue ID: 9953
Summary: Push replication issue for the pwdHistory attribute
Product: OpenLDAP
Version: 2.4.57
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: dh(a)dotlan.net
Target Milestone: ---
Hello,
I'm using a master ldap instance with a push replication instance to external
slaves using the ldap backend on Debian 11 (2.4.57) and I came across some
replication issues that forces me to drop the slave dbs and do a manually
fullsync everything this error occurs.
The problem
===========
I know that replication and maintaining a password policy is a complicated
task, especially since the ppolicy overlay must be loaded and active in every
instance (master, push instance, slave). This problem leads to interesting
challanges.
First, I encountered a problem where pwdChangedTime would be duplicate because
the ppolicy overlay of the push instance and the back_ldap/slave instance would
like to set it (which leads to a duplicate attribute error). To fix problem I
backported the patch [1] to my local version of the slapd packages. After this
problem was fixed, I've encountered the next problematic attribute:
"pwdHistory". I've play around with some syncrepl settings, but in the end, it
seems to be a similar issue. It looks likes the pwdHistory attribute is not yet
present on the slave and both instances (push and slave) try to add the
pwdHistory Attributes which leads to a problem where both entries collied
(pwdHistory: value #0 already exists). For whatever reason pwdHistory doesn't
show up as modified field on the slave in the MOD request. But anyways.
Something seems to be wrong, and it could a similar replication issue compared
with pwdChangedTime
I've lookup into the change history of the ppolicy.c file in the 2.5 and 2.6
branch but couldn't find a newer commit that would address this issue.
Does anyone has encountered a similar issue? I've not played around with the
2.5 or 2.6 version, but looking at the code, I've either not seen a fix or the
problem might still exist, hopefully I am wrong. Any suggestions?
--
best regards
Daniel Hoffend
[1]
https://github.com/openldap/openldap/commit/7a34f46d1cabe8e80937d5167b621...
Setup
=====
Host Master
- Debian 11 slapd 2.4.57+dfsg-3
- slapd master instance with cn=config
- push replikation instance with simple config (syncrepl from localhost, write
to backend ldap)
Host Slave
- Debian 11 slapd 2.4.57+dfsg-3
- Readonly slave
On all 3 instances ppolicy is enabled otherwise the operational attributes
would be not known/available and sync of locked accounts or per account
selected password policy assignment wouldn't work.
PUSH Replication Instance
=========================
database ldap
[...]
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=example,dc=org"
syncrepl rid=__RID__
provider=ldap://localhost:389/
binddn="cn=replication,ou=system,dc=example,dc=org"
bindmethod=simple
credentials="secret"
searchbase="dc=example,dc=org"
type=refreshAndPersist
schemachecking=off
retry="5 12 60 +"
attrs="*,memberOf,pwdPolicySubentry,pwdChangedTime,pwdAccountLockedTime,pwdHistory,creatorsName,createTimestamp,modifiersName,modifyTimestamp"
---
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_message_to_entry: rid=016
DN: uid=user1,ou=accounts,dc=example,dc=org, UUID:
db720f56-df0d-103c-8635-9543ccd6e97d
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid a0a89700
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_search
(0)
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016
uid=user1,ou=accounts,dc=example,dc=org
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_null_callback : error code
0x14
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify
uid=user1,ou=accounts,dc=example,dc=org (20)
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify
failed (20)
Nov 3 00:00:45 ldapmaster slapd[2308611]: do_syncrepl: rid=016 rc 20 retrying
SLAVE LDAP Server
=================
database mdb
[...]
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=example,dc=org"
---
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SRCH
base="uid=user1,ou=accounts,dc=example,dc=org" scope=0 deref=0
filter="(objectClass=*)"
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD
dn="uid=user1,ou=accounts,dc=example,dc=org"
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD
attr=structuralObjectClass creatorsName createTimestamp userPassword
pwdChangedTime memberOf entryCSN modifiersName modifyTimestamp
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 RESULT tag=103
err=20 text=modify/add: pwdHistory: value #0 already exists
--
You are receiving this mail because:
You are on the CC list for the issue.
4 months, 3 weeks
[Issue 9998] New: Potential memory leak in tests/progs/slapd-mtread.c
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9998
Issue ID: 9998
Summary: Potential memory leak in tests/progs/slapd-mtread.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in slapd-mtread.c line 520.Calling ldap_search_ext_s()
without calling ldap_msgfree() to free the memory will cause a memory leak.
Doc says "Note that res parameter of ldap_search_ext_s() and
ldap_search_s() should be freed with ldap_msgfree() regardless of return value
of these functions." in
https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos...
--
You are receiving this mail because:
You are on the CC list for the issue.
4 months, 3 weeks
[Issue 10035] New: TLSv1.3 cipher suites can be set incorrectly
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=10035
Issue ID: 10035
Summary: TLSv1.3 cipher suites can be set incorrectly
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ipuleston(a)sonicwall.com
Target Milestone: ---
I noticed that, on the client side, when I use LDAP_OPT_X_TLS_CIPHER_SUITE to
set an OpenSSL cipher-suites list that contains a TLSv1.3 cipher suite, that
may or may not get set correctly, depending on where it is located in the list.
The following is what I am seeing with TLS versions 1.2 and 1.3 enabled:
If I set this cipher-suites list:
"3DES:TLS_AES_128_GCM_SHA256:!eNULL"
Then WireShark shows shows it offering these ciphers in the TLS Client Hello,
which is correct (the single given TLSv1.3 suite, plus 6 using 3-DES):
Cipher Suites (7 suites)
Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
However, if I set this cipher-suites list:
"!eNULL:3DES:TLS_AES_128_GCM_SHA256"
Then it now incorrectly offers two additional TLSv1.3 suites:
Cipher Suites (9 suites)
Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Those first three are all of the TLSv3 ciphers supported by OpenSSL in this
system.
--
You are receiving this mail because:
You are on the CC list for the issue.
4 months, 3 weeks