Sponsored Content
Full Discussion: Solaris LDAPCLIENT accept CA
Homework and Emergencies Emergency UNIX and Linux Support Solaris LDAPCLIENT accept CA Post 302606659 by s ladd on Monday 12th of March 2012 10:44:49 AM
Old 03-12-2012
Solaris LDAPCLIENT accept CA

Hey Guys,
How can I make the Solaris native ldapclient trust a CA? I am trying to use a selfsigned cert and it is not working. WHen I use ssltap to monitor the ssl traffic it shows this for the last client communication:

0: 15 03 01 00 02 02 30 | ......0
(7 bytes of 2)
SSLRecord { [Mon Mar 12 14:32:06 2012]
0: 15 03 01 00 02 | .....
type = 21 (alert)
version = { 3,1 }
length = 2 (0x2)
fatal: unknown_ca
0: 02 30

The server is Oracle Directory Server 11.xxx
 

10 More Discussions You Might Find Interesting

1. HP-UX

accept problem

Hi, there On HP-UX IA server, when calling 'accept' function in my program, the server never wait the client's connection. Each time, it accepted the request from IP address 0.0.0.0 even there is no client's connection. The server program looks like : main() { . . .... (4 Replies)
Discussion started by: Frank2004
4 Replies

2. Solaris

How to enable solaris 9 to accept remote XDMCP

Hi, I want to enable solaris 9 to accept remote XDMCP connections. Please let me know what places i should look into and what configurations to be made. Thanks (1 Reply)
Discussion started by: 0ktalmagik
1 Replies

3. Solaris

Solaris 10 install won't accept IP address

Hi I am trying to debug an issue with an automated install I have set-up. So to start I just ran a simple ok; boot cdrom - install but when it came to the IP address field it would only take the following format 123.123.123.12 and would not let me enter the last digit Anybody got any... (9 Replies)
Discussion started by: eeisken
9 Replies

4. Solaris

Citrix cannot accept any connections in solaris 9

We have installed Citrix server in Solaris 9 (Sparc Ultra45), we are able to connect from windows workstations to Citrix Server. But today Suddenly we got the error Citrix server cannot accept any connections. I am not aware of citrix server, All citrix user Please help me in this regard what... (1 Reply)
Discussion started by: durgaprasadr13
1 Replies

5. Solaris

configure ldapclient on solaris 10

Hi there, I am looking for a detailed step-by-step how to configure ldapclient on solaris 10. I used ldapclient manual, and edited nsswitch.conf and pam.conf, but it is not working. thank you (2 Replies)
Discussion started by: trtcom1
2 Replies

6. Solaris

Error in LdapClient configuration

Hi all, My code for configuring ldapclient is as follows: ldapclient manual \ -a credentialLevel=proxy \ -a authenticationMethod=simple \ -a proxyDN=cn=proxyagent,cn=user1,dc=sema,dc=com \ -a proxyPassword=user1 \ -a defaultSearchBase=dc=sema,dc=com \ -a domainName=sema.com \ -a... (10 Replies)
Discussion started by: sathya47
10 Replies

7. UNIX for Advanced & Expert Users

ln -s accept wildcards?

Does ln -s accept wildcards? It doesn't seem like it is working when I use wildcards. (9 Replies)
Discussion started by: cokedude
9 Replies

8. Solaris

ldapclient can not modify attribute

Hello, We have one Solaris 10 machine which has three LDAP servers configured. We want to remove one of them. I tried below ldapclient command however no change is made. ---------------------------------------------------------------------- ldapclient mod -a "defaultServerList=10.149.9.20... (0 Replies)
Discussion started by: alfa_w
0 Replies

9. Solaris

Help with Solaris 10 and ldapclient authentication

Hello everyone! Currently, i have a RHEL6 server, with openLDAP server running. Most of our servers run on Rhel platform, but some of them run in Solaris 10, and I need to make them authenticate with ldap too. As the ldap server is running without encryption, the command I used for initialize... (13 Replies)
Discussion started by: Lilbighorn
13 Replies

10. Solaris

Configure Solaris to accept Active Directory user logins

Is it possible to configure a Solaris server to authenticate users against an Active Directory server when logging in via ssh? I've seen some docs out there, I've followed their instructions, but it does not work. And I'm beginning to wonder if it is possible or even supported by Oracle. The... (2 Replies)
Discussion started by: BG_JrAdmin
2 Replies
SSL_alert_type_string(3)					      OpenSSL						  SSL_alert_type_string(3)

NAME
SSL_alert_type_string, SSL_alert_type_string_long, SSL_alert_desc_string, SSL_alert_desc_string_long - get textual description of alert information SYNOPSIS
#include <openssl/ssl.h> const char *SSL_alert_type_string(int value); const char *SSL_alert_type_string_long(int value); const char *SSL_alert_desc_string(int value); const char *SSL_alert_desc_string_long(int value); DESCRIPTION
SSL_alert_type_string() returns a one letter string indicating the type of the alert specified by value. SSL_alert_type_string_long() returns a string indicating the type of the alert specified by value. SSL_alert_desc_string() returns a two letter string as a short form describing the reason of the alert specified by value. SSL_alert_desc_string_long() returns a string describing the reason of the alert specified by value. NOTES
When one side of an SSL/TLS communication wants to inform the peer about a special situation, it sends an alert. The alert is sent as a special message and does not influence the normal data stream (unless its contents results in the communication being canceled). A warning alert is sent, when a non-fatal error condition occurs. The "close notify" alert is sent as a warning alert. Other examples for non-fatal errors are certificate errors ("certificate expired", "unsupported certificate"), for which a warning alert may be sent. (The sending party may however decide to send a fatal error.) The receiving side may cancel the connection on reception of a warning alert on it discretion. Several alert messages must be sent as fatal alert messages as specified by the TLS RFC. A fatal alert always leads to a connection abort. RETURN VALUES
The following strings can occur for SSL_alert_type_string() or SSL_alert_type_string_long(): "W"/"warning" "F"/"fatal" "U"/"unknown" This indicates that no support is available for this alert type. Probably value does not contain a correct alert message. The following strings can occur for SSL_alert_desc_string() or SSL_alert_desc_string_long(): "CN"/"close notify" The connection shall be closed. This is a warning alert. "UM"/"unexpected message" An inappropriate message was received. This alert is always fatal and should never be observed in communication between proper imple- mentations. "BM"/"bad record mac" This alert is returned if a record is received with an incorrect MAC. This message is always fatal. "DF"/"decompression failure" The decompression function received improper input (e.g. data that would expand to excessive length). This message is always fatal. "HF"/"handshake failure" Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security parame- ters given the options available. This is a fatal error. "NC"/"no certificate" A client, that was asked to send a certificate, does not send a certificate (SSLv3 only). "BC"/"bad certificate" A certificate was corrupt, contained signatures that did not verify correctly, etc "UC"/"unsupported certificate" A certificate was of an unsupported type. "CR"/"certificate revoked" A certificate was revoked by its signer. "CE"/"certificate expired" A certificate has expired or is not currently valid. "CU"/"certificate unknown" Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable. "IP"/"illegal parameter" A field in the handshake was out of range or inconsistent with other fields. This is always fatal. "DC"/"decryption failed" A TLSCiphertext decrypted in an invalid way: either it wasn't an even multiple of the block length or its padding values, when checked, weren't correct. This message is always fatal. "RO"/"record overflow" A TLSCiphertext record was received which had a length more than 2^14+2048 bytes, or a record decrypted to a TLSCompressed record with more than 2^14+1024 bytes. This message is always fatal. "CA"/"unknown CA" A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or couldn't be matched with a known, trusted CA. This message is always fatal. "AD"/"access denied" A valid certificate was received, but when access control was applied, the sender decided not to proceed with negotiation. This mes- sage is always fatal. "DE"/"decode error" A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This mes- sage is always fatal. "CY"/"decrypt error" A handshake cryptographic operation failed, including being unable to correctly verify a signature, decrypt a key exchange, or validate a finished message. "ER"/"export restriction" A negotiation not in compliance with export restrictions was detected; for example, attempting to transfer a 1024 bit ephemeral RSA key for the RSA_EXPORT handshake method. This message is always fatal. "PV"/"protocol version" The protocol version the client has attempted to negotiate is recognized, but not supported. (For example, old protocol versions might be avoided for security reasons). This message is always fatal. "IS"/"insufficient security" Returned instead of handshake_failure when a negotiation has failed specifically because the server requires ciphers more secure than those supported by the client. This message is always fatal. "IE"/"internal error" An internal error unrelated to the peer or the correctness of the protocol makes it impossible to continue (such as a memory allocation failure). This message is always fatal. "US"/"user canceled" This handshake is being canceled for some reason unrelated to a protocol failure. If the user cancels an operation after the handshake is complete, just closing the connection by sending a close_notify is more appropriate. This alert should be followed by a close_notify. This message is generally a warning. "NR"/"no renegotiation" Sent by the client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these would normally lead to renegotiation; when that is not appropriate, the recipient should respond with this alert; at that point, the original requester can decide whether to proceed with the connection. One case where this would be appropriate would be where a server has spawned a process to satisfy a request; the process might receive security parameters (key length, authentication, etc.) at startup and it might be difficult to communicate changes to these parameters after that point. This message is always a warning. "UK"/"unknown" This indicates that no description is available for this alert type. Probably value does not contain a correct alert message. SEE ALSO
ssl(3), SSL_CTX_set_info_callback(3) 0.9.7a 2001-09-07 SSL_alert_type_string(3)
All times are GMT -4. The time now is 05:33 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy