I have implemented a connector to different kinds of webservice with JAX-WS in weblogic 10.3.6, the connector can be configured with 2waySSL, proxy and combine both of them.
The implementation to use proxy works properly using ClientProxyFeature.
In the same way with 2waySSL using a custom SSLSocketFactory as Oracle says in the documentation. Persisting the State of a Request over SSL (JAX-WS Only)
((BindingProvider) port).getRequestContext().put(
JAXWSProperties.SSL_SOCKET_FACTORY,
SSLClientUtil.getSSLSocketFactoryFromSysProperties());
The issue occurs when combine both features. The handshake does not happend (ClientHello)
The error is:
ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)', READ: TLSv1.2 Alert, length = 64
Padded plaintext after DECRYPTION: len = 64
0000: F0 E5 6E 9F 6F F4 BB 2E 07 29 56 FE 34 0A 10 0B ..n.o....)V.4...
0010: 02 28 7E 75 92 F7 03 4E CD 3A 7E 0B E2 6A 7C 8E .(.u...N.:...j..
0020: 3B F8 4E F5 98 A3 D3 B4 67 76 20 49 1B 77 07 5E ;.N.....gv I.w.^
0030: 9D 66 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D 0D .f..............
[ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)', RECV TLSv1.2 ALERT: fatal, handshake_failure
[ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)', fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: handshake_failure
[ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)', fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: handshake_failure
<13-sep-2017 09H32' CEST> <Debug> <SecuritySSL> <BEA-000000> <[Thread[[ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads]]weblogic.security.SSL.jsseadapter: SSLENGINE: Exception occurred during SSLEngine.unwrap(ByteBuffer,ByteBuffer[]).
javax.net.ssl.SSLException: Received fatal alert: handshake_failure
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:188)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1614)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1582)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1751)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1043)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:865)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:740)
Debuging and decompiling weblogic source I can see that the HttpsClient when use proxy does not use the custom SSLSocketFactory.
1) In the transport class weblogic.wsee.jaxws.transport.http.client.HttpClientTransport weblogic opens the connection:
protected HttpURLConnection openConnection(Packet paramPacket)
…
localSSLSocketFactory = (javax.net.ssl.SSLSocketFactory)this.context.invocationProperties.get("com.sun.xml.ws.transport.https.client.SSLSocketFactory");
if ((localSSLSocketFactory != null) && ((localSSLSocketFactory instanceof javax.net.ssl.SSLSocketFactory)))
{
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.fine("set (jdk) ssl socketfactory to wls socketfactory");
}
((weblogic.net.http.HttpsURLConnection)localObject3).setSSLSocketFactory(new MySSLSocketFactory((javax.net.ssl.SSLSocketFactory)localSSLSocketFactory));
}
…
As you can see, set the custom SSLSocketFactory.
2) Without a proxy, the weblogic.net.http.HttpsClient uses the custom SSLSocketFactory to create the socket
this.serverSocket = localSocketFactory.createSocket(arrayOfInetAddress[i], paramInt);
The localSocketFactory is the custom SSLSocketFactory.
3) But if uses proxy then create a new SSLSocketFactory
private void makeConnectionUsingProxy(String s, int i, boolean flag)
throws IOException
{
javax.net.ssl.SSLSocketFactory sslsocketfactory;
int j;
SSLContextWrapper sslcontextwrapper = SSLSetup.getSSLContext(sslInfo);
sslcontextwrapper.getHostnameVerifier().setProxyMapping(s, host);
sslcontextwrapper.getTrustManager().setProxyMapping(s, host);
sslsocketfactory = sslcontextwrapper.getSSLSocketFactory();
The sslInfo is an object without the keystore or truststore informed in the SSLSocketFactory. I haven't seen any way to inform the object sslInfo (weblogic.security.SSL.SSLClientInfo)
The variables to start the weblogic are the next:
-Dweblogic.security.SSL.nojce=true -Djavax.net.debug=all -Dssl.debug=true
-Djavax.net.ssl.keyStore=XXXXXs -Djavax.net.ssl.keyStorePassword=XXXXX
-Djdk.tls.enableRC4CipherSuites=true -Djsse.enableSNIExtension=false -Dweblogic.ssl.JSSEEnabled=true -Dweblogic.security.SSL.enableJSSE=true -Dweblogic.security.SSL.nojce=true -Dweblogic.security.SSL.ignoreHostnameVerification=true
The custom SSLSocketFactory is create with this params and with the default trustore. When no proxy is used everything works propertly.
I don't understand why to make the connection with a proxy weblogic does not use the same SSLSocketFactory.
Any ideas?
Oracle people have confirm us that is a "bug" in this implementation, it is only possible to solve with the property -DUseSunHttpHandler=true.
In Oracle 12 you can use the setter method setUseSunHttpHandler of the ClientProxyFeature. But with the weblogic implementation is not possible to solve.
Related
I am new to SSL and the Boost-Beast library, and also C++, but that's a different story.
I have a question regarding using HTTPS (SSL) with Beast. I am going to use the library to connect to a REST service and post JSON to a server where I do not control the certificates, the API etc.
And it kind of works.
The thing is that I do not clearly understand HOW it works. In the example that comes with Beast it is referenced to a file example/common/root_certificates.hpp where it is two certificates in base64 format or something like that.
When I tried the example, I got it to work with POST a JSON string to a server, let's call it "exampleserver.com". Connected to both port 80 and 443. Even though I commented out the line where it calls the root certificate function, load_root_certificates(ctx);. No errors from handshaking or anything else showed up. And the server responded correctly.
So, my questions are then:
1) Did the Beast library get the certificate from exampleserver.com or did I already have it installed and that's why it worked? If so what happens when it expires? Do I have to reinstall a new one on every client that uses my application?
I would prefer to not have any hardcoded certificates in my code to check it upon. The certificate says DigiCert Global Root CA -> DigiCert SHA2 Secure Server CA is that a standard certificate maybe that comes with the browser?
2) Did it just use plain HTTP over port 443 (no SSL)? Don know if this is possible at all...
Even though I commented out the line where it calls the root certificate funtion, "load_root_certificates(ctx);"
In that case, openssl uses the systemwide default certificate store (e.g. on linux /etc/ssl/certs), so the "usual" authorities will be trusted (just like e.g. your browser does).
1) Did the Beast library get the certificate from "exampleserver.com" or did I already have it installed and thats why it worked?
Yes.
If so what happens when it expires?
It will fail to verify. Test it, if you want: https://expired.badssl.com/
That site has many excellent SSL tests (https://badssl.com)
The certificate says "DigiCert Global Root CA -> DigiCert SHA2 Secure Server CA" is that a standard certificate maybe that comes with the browser?
The browser's trusted certificates aren't relevant (you're not using the browser). However, you can see openssl's (see above), or you can test using something like
openssl s_client -connect exampleserver.com:443 -verify -showcerts
Which prints something similar to
verify depth is 0
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority
verify return:1
depth=1 C = US, ST = TX, L = Houston, O = "cPanel, Inc.", CN = "cPanel, Inc. Certification Authority"
verify return:1
depth=0 CN = tradingfleet.com
verify return:1
---
Certificate chain
0 s:/CN=tradingfleet.com
i:/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
1 s:/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFUjCCBDqgAwIBAgIQPI9I0oyjgNMrudesOYyqgDANBgkqhkiG9w0BAQsFADBy
MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVFgxEDAOBgNVBAcTB0hvdXN0b24xFTAT
BgNVBAoTDGNQYW5lbCwgSW5jLjEtMCsGA1UEAxMkY1BhbmVsLCBJbmMuIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MB4XDTE4MDIxODAwMDAwMFoXDTE4MDUxOTIzNTk1
OVowGzEZMBcGA1UEAxMQdHJhZGluZ2ZsZWV0LmNvbTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBANe5zu81biDwwIloBMFHWc2OvoiGTNBr2aya8auWrzRm
rmbOfugZOaIAms79jnINCQ7jy0Qk2xwblgCifCg7y/UfSXvv7IWUWcEDywsAoyz/
sUc9myvQbot+kD1DaxVoyN85LnDehaYF5+myDznJISQe1ei01n/aIF8gwOz4k3Gn
R07Zh0sDRBjIiRsAL6ZljrPRk47cul2+8pD0qNJHHN0QX6hz/KPOugTiivI1+ymo
onSeeN29oh5oTtCHP2yj9+RNsCNcPAnbDawy0RAgFi2W5GyHiIo/NkUxBXN8tQxH
2xrPnY+MQJHUcKXJd//DTX6tWoQqo4xisN6Q9iZ3+R8CAwEAAaOCAjkwggI1MB8G
A1UdIwQYMBaAFH4DWmVBa6d+CuG4nQjqHY4dasdlMB0GA1UdDgQWBBQKTFmhmBNx
pS9uBbXjqE1ZjCOiFjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwTwYDVR0gBEgwRjA6BgsrBgEEAbIx
AQICNDArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8uY29tL0NQ
UzAIBgZngQwBAgEwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9j
YS5jb20vY1BhbmVsSW5jQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwfQYIKwYB
BQUHAQEEcTBvMEcGCCsGAQUFBzAChjtodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9j
UGFuZWxJbmNDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNydDAkBggrBgEFBQcwAYYY
aHR0cDovL29jc3AuY29tb2RvY2EuY29tMIGXBgNVHREEgY8wgYyCEHRyYWRpbmdm
bGVldC5jb22CF2NwYW5lbC50cmFkaW5nZmxlZXQuY29tghVtYWlsLnRyYWRpbmdm
bGVldC5jb22CGHdlYmRpc2sudHJhZGluZ2ZsZWV0LmNvbYIYd2VibWFpbC50cmFk
aW5nZmxlZXQuY29tghR3d3cudHJhZGluZ2ZsZWV0LmNvbTANBgkqhkiG9w0BAQsF
AAOCAQEAPFIZv1oHXm79+uoLnP9Sya2qEghOn/uPpNtappgUSrh2Pb0MueX84C0P
4HRS4yHRO1TD9ZOfCuPsguzXhl+RUB7Asl2iAhwthoZGMLhv6uaUnAUHZbpdkJY3
r/quuWHXDGNoe2quAOxGLPDO7WMvrDh1hFi7x7AGshkRSZ4DREBnCS7iprKzKL6H
BaNqtAlWgoXcSSg1RpnbU2o4bWIv8mZG0ATr7Cc8VSf04SjBLZnLTNeqo6Z+ALQ3
yrFsAytim6857FB231V5NEvLh+iZjSOuBG9xv+4Nw46bVz9z8QxB3czAodrDGXbB
lgH1s5f486lRq45dRn/hGY+DZjJXgg==
-----END CERTIFICATE-----
subject=/CN=tradingfleet.com
issuer=/C=US/ST=TX/L=Houston/O=cPanel, Inc./CN=cPanel, Inc. Certification Authority
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4988 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 24CB439538212A23E0391887F856E369858AB6864B25DA5F1FD618550C41EB92
Session-ID-ctx:
Master-Key: 1B8A3028923478527196B429D10F3584C5FA5DE4175C834CBBEF9EB19013FBFE58E7668CED9C0877E15F4F214A61F80C
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - ca 83 5a 76 c2 51 7b c7-68 15 12 a7 cb c9 f5 35 ..Zv.Q{.h......5
0010 - 0a dc c1 2a 90 fd 61 69-0a d9 89 09 f0 c4 b3 40 ...*..ai.......#
0020 - 79 dc 97 8a c5 0d a1 67-85 5e b4 25 47 94 ed 23 y......g.^.%G..#
0030 - 42 df b2 99 25 ec b1 fa-d7 3e 3e 24 37 ef 67 ef B...%....>>$7.g.
0040 - 56 f4 d2 57 cd 47 48 bd-d7 86 b1 2f b5 76 d6 db V..W.GH..../.v..
0050 - 12 9d 7a d3 94 b0 58 bf-c5 c4 3e 7d 05 98 75 1d ..z...X...>}..u.
0060 - 31 bc 9b 23 4f a7 ce 37-af 77 8a 96 89 20 20 64 1..#O..7.w... d
0070 - 3d bf de 25 b2 09 02 20-49 09 b5 57 a1 c3 75 ed =..%... I..W..u.
0080 - 97 ec 51 d2 46 f7 c6 b7-4a d8 b2 db 95 eb ac d6 ..Q.F...J.......
0090 - be 76 14 80 ca 08 dc b7-b6 cb e9 c9 cc 8b 45 bd .v............E.
00a0 - d7 1d a7 88 9b a4 91 33-aa 23 fe 23 65 b8 e1 d9 .......3.#.#e...
00b0 - 98 f6 55 1e 25 32 97 b5-22 ac d0 58 01 a6 42 60 ..U.%2.."..X..B`
Start Time: 1522150150
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
^C
2) Did it just use plain http over port 443 (no SSL)? Don know if this is possible at all...
No it didn't.
It's possible only given a whacky server config, but usually if your server connects https from a browser, it will be impossible to connect plain:
https://askubuntu.com/questions/860511/is-it-possible-to-set-same-port-work-with-http-and-https
on whacky configs: Nodejs HTTP and HTTPS over same port
As suggested by Vinnie Falco, in the file example/common/root_certificates.hpp, use the following header only library https://github.com/djarek/certify
In your code add the following includes
#include <boost/certify/extensions.hpp>
#include <boost/certify/https_verification.hpp>
And replace the initial code:
// This holds the root certificate used for verification
load_root_certificates(ctx);
// Verify the remote server's certificate
ctx.set_verify_mode(ssl::verify_peer);
by this:
ctx.set_verify_mode(ssl::context::verify_peer );
boost::certify::enable_native_https_server_verification(ctx);
Tested quickly with site badssl.com and sites with good ssl certificate. And it's work like a charm.
Possibly, you already figured it out by now.
I tried the same beast sample (Boost libraries 1.70) and had to make the following change to the ctor of session (I did it there it may be possible to make the change at some other place in code as well):
ws_.next_layer().set_verify_mode(boost::asio::ssl::verify_peer);
ws_.next_layer().set_verify_callback(std::bind(&session::verify_certificate, this, _1, _2));
and added a method (that I copied as is from the Asio client sample):
bool verify_certificate(bool pverified_ok, ssl::verify_context& ctx)
{
char subject_name[256];
X509 *cert = X509_STORE_CTX_get_current_cert(ctx.native_handle());
X509_NAME_oneline(X509_get_subject_name(cert), subject_name, 256);
std::cout << "Verifying " << subject_name << std::endl;
return pverified_ok;
}
This change causes the verification to fail (I had removed the hard-coded certificates since I did not want to use those). The callback assists in logging that the server certificate was actually being verified.
Just like the Asio sample adding a CA certificate to the ssl::context e.g.
boost::asio::ssl::context ctx(boost::asio::ssl::context::sslv23);
ctx.load_verify_file("ca.pem"); // CA certificate
Causes the verification to pass.
You need to create the self-signed CA certificate and server certificate signed by it and place it in the server code (again from Asio sample) e.g.
context_.use_certificate_chain_file("..\\sample-server1.pem");
context_.use_private_key_file("..\\sample-server1-key.pem", boost::asio::ssl::context::pem);
context_.use_tmp_dh_file("..\\dh2048.pem");
PSNMP Socket is actually receiving traps but the call back function is not getting called. I have enabled the debug logging. Using Pysnmp 4.3.3
from pysnmp.entity import engine, config
from pysnmp.carrier.asyncore.dgram import udp
from pysnmp.entity.rfc3413 import ntfrcv
from pysnmp.proto.api import v2c
from pysnmp.smi import builder, view, compiler, rfc1902, error
from pysnmp import debug
debug.setLogger(debug.Debug('all'))
snmpEngine = engine.SnmpEngine()
config.addTransport(
snmpEngine,
udp.domainName,
udp.UdpTransport().openServerMode(('0.0.0.0', 1036))
)
config.addV3User(
snmpEngine, 'user_snmp1234'
)
def cbFun(snmpEngine, stateReference, contextEngineId, contextName,
varBinds, cbCtx):
print "#######################Recived Notification from {} #######################".format(snmpEngine.msgAndPduDsp.getTransportInfo(stateReference)[-1][0])
for oid, val in varBinds:
output = rfc1902.ObjectType(rfc1902.ObjectIdentity(oid),
val).resolveWithMib(mibViewController).prettyPrint()
print output
ntfrcv.NotificationReceiver(snmpEngine, cbFun)
snmpEngine.transportDispatcher.jobStarted(1)
try:
snmpEngine.transportDispatcher.runDispatcher()
except:
snmpEngine.transportDispatcher.closeDispatcher()
raise
I can see its reciving the v3 traps:
2017-02-24 00:46:02,853 pysnmp: prepareDataElements: SNMPv3Message:
msgVersion=3
msgGlobalData=HeaderData:
msgID=16259
msgMaxSize=65535
msgFlags=0x00
msgSecurityModel=3
msgSecurityParameters=0x3027040c80000f150000000000000000020100020100040d757365725f736e6d703132333404000400
msgData=ScopedPduData:
plaintext=ScopedPDU:
contextEngineId=0x80000f150000000000000000
contextName=
data=PDUs:
snmpV2-trap=SNMPv2TrapPDU:
request-id=775985686
error-status='noError'
error-index=0
variable-bindings=VarBindList:
VarBind:
name=1.3.6.1.2.1.1.3.0
=_BindValue:
value=ObjectSyntax:
application-wide=ApplicationSyntax:
timeticks-value=10000
But at the end I am gating some error like this :
2017-02-24 00:46:02,853 pysnmp: prepareDataElements: msg data msgVersion 3 msgID 16259 securityModel 3
2017-02-24 00:46:02,854 pysnmp: processIncomingMsg: securityParameters
00000: 30 27 04 0C 80 00 0F 15 00 00 00 00 00 00 00 00
00016: 02 01 00 02 01 00 04 0D 75 73 65 72 5F 73 6E 6D
00032: 70 31 32 33 34 04 00 04 00
2017-02-24 00:46:02,854 pysnmp: processIncomingMsg: UsmSecurityParameters:
msgAuthoritativeEngineId=0x80000f150000000000000000
msgAuthoritativeEngineBoots=0
msgAuthoritativeEngineTime=0
msgUserName=user_snmp1234
msgAuthenticationParameters=
msgPrivacyParameters=
2017-02-24 00:46:02,855 pysnmp: processIncomingMsg: cache write securityStateReference 6156330 by msgUserName user_snmp1234
2017-02-24 00:46:02,855 pysnmp: processIncomingMsg: unsynchronized securityEngineID OctetString(hexValue='80000f150000000000000000')
2017-02-24 00:46:02,855 pysnmp: processIncomingMsg: read from securityParams msgAuthoritativeEngineId OctetString(hexValue='80000f150000000000000000') msgUserName OctetString('user_snmp1234', subtypeSpec=ConstraintsIntersection(ConstraintsIntersection(), ValueSizeConstraint(0, 32)))
2017-02-24 00:46:02,855 pysnmp: processIncomingMsg: unknown securityEngineID OctetString(hexValue='80000f150000000000000000') msgUserName OctetString('user_snmp1234', subtypeSpec=ConstraintsIntersection(ConstraintsIntersection(), ValueSizeConstraint(0, 32)))
2017-02-24 00:46:02,855 pysnmp: StatusInformation: {'securityLevel': 1, 'contextName': '', 'val': Counter32(3), 'contextEngineId': SnmpEngineID(), 'oid': (1, 3, 6, 1, 6, 3, 15, 1, 1, 3, 0), 'maxSizeResponseScopedPDU': 65446, 'securityStateReference': 6156330, 'errorIndication': <pysnmp.proto.errind.UnknownSecurityName object at 0x7f1c3d7cf910>}
2017-02-24 00:46:02,855 pysnmp: prepareDataElements: SM failed, statusInformation {'securityLevel': 1, 'contextName': '', 'val': Counter32(3), 'contextEngineId': SnmpEngineID(), 'oid': (1, 3, 6, 1, 6, 3, 15, 1, 1, 3, 0), 'maxSizeResponseScopedPDU': 65446, 'securityStateReference': 6156330, 'errorIndication': <pysnmp.proto.errind.UnknownSecurityName object at 0x7f1c3d7cf910>}
2017-02-24 00:46:02,855 pysnmp: returnResponsePdu: PDU <empty>
2017-02-24 00:46:02,855 pysnmp: prepareResponseMessage: stateReference 9434948
2017-02-24 00:46:02,856 pysnmp: StatusInformation: {'errorIndication': <pysnmp.proto.errind.LoopTerminated object at 0x7f1c3d7cf290>}
2017-02-24 00:46:02,856 pysnmp: prepareDataElements: error reported
SNMPv3 TRAPs mandate you configuring SNMP Engine ID of the TRAP sending application to USM users table of TRAP receiving application for each USM user:
config.addV3User(
snmpEngine, 'user_snmp1234',
securityEngineId=v2c.OctetString(hexValue='8000000001020304')
)
So you should either configure (or figure out in device configuration) authoritative SNMP engine ID of your TRAP sending apps or devices, then configure them into your TRAP receiver.
If you are struggling figuring out SNMP engine ID of your devices, try this tool -- it will talk to your device and report its SNMP engine ID.
This is how you could send TRAP with Net-SNMP snmptrap tool setting its SNMP engine ID to specific value:
$ snmptrap -v3 -u user_snmp1234 -l noAuthNoPriv -e 8000000001020304 127.0.0.1 123 1.3.6.1.6.3.1.1.5.1
As explained by the first link, all that complications are due to the fact that (otherwise automatic) SNMP engine ID discovery does not over unidirectional messaging such as TRAPs.
I created custom authentication by Wcf after that I created self-sign ssl in IIS 7.5
and use below code in web.config
<serviceCertificate findValue="CN = srv-erp"/>
and this one too
<serviceCertificate findValue="CN = srv-erp"
storeLocation="LocalMachine"
x509FindType="FindBySubjectName"
storeName="My"/>
and I used FindBySerialNumber too.
but they didn't work and I get this error
Cannot find the X.509 certificate using the following search criteria:
StoreName 'My', StoreLocation 'LocalMachine', FindType
'FindBySubjectDistinguishedName', FindValue 'CN = srv-erp'.
Your help is appreciated
it seems that problem in the findValue property try to change it to serv-erp. You don't need to place key of property in findValue when you use x509FindType.
<serviceCertificate findValue="srv-erp"
storeLocation="LocalMachine"
x509FindType="FindBySubjectName"
storeName="My"/>
Also you may try to find you certificate by another type (see X509FindType reference) For instance, by thumbprint
<serviceCertificate storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint"
findValue="b5 ca b7 d0 b8 da fd 20 b7 bb 14 5d 66 2b 53 f3 0c 20 ca f2"/>
Finally, ensure that your certificate is exist. Type Run in Search Windows and copy and paste certmgr.msc. Then on the menu click on Action -> Find certificates...
So I have been searching high and low for how to validate my server's certificate from within OpenSSL in a C++ application I am developing, and I finally got a hint. However, I am still missing a few steps.
So I found out that OpenSSL has a ssl client application called s_client. When I use the following command:
echo -n | openssl s_client -connect mywebsite.me:443 -debug | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > my.cert
I receive this error as I do within my application:
verify error:num=20:unable to get local issuer certificate
It's not until I did some more searching that I found out what the error meant and that I had to do the following:
echo -n | openssl s_client -connect mywebsite.me:443 -debug | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > my.cert
echo -n | openssl s_client -connect mywebsite.me:443 -debug -CAfile my.cert
The first command connects, receives a response, saves it to a file, but fails to validate the response. The second reconnects sending the saved file and allows the certificate to be properly verified.
My question is, how can I grab the stream that is being send to sed and send "my.cert" in c/c++ preferably in one connect? I have been walking the s_client code but can't seem to find it.
openssl s_client -connect mywebsite.me:443 -debug
...
I receive this error as I do within my application:
verify error:num=20:unable to get local issuer certificate
mywebsite.me is certifed by Go Daddy. In particular, Go Daddy Class 2 Certification Authority.
$ openssl s_client -connect mywebsite.me:443
CONNECTED(00000003)
depth=2 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/O=breezi.com/OU=Domain Control Validated/CN=breezi.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
...
Navigate to Go Daddy Repository, SSL Certificate Information and fetch Go Daddy Class 2 Certification Authority Root Certificate. You can't do a simple wget with a URL because GoDaddy has f**k'd up the download with javascript (it fetches a web page rather then the certificate). The GoDaddy root is saved as gd-class2-root.crt.
Then, run openssl s_client again with the -CAfile option. The certificate is expired, so you'll receive Verify return code: 10 (certificate has expired). But it clears the trust issue.
$ openssl s_client -CAfile gd-class2-root.crt -connect mywebsite.me:443
CONNECTED(00000003)
depth=2 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certificates.godaddy.com/repository, CN = Go Daddy Secure Certification Authority, serialNumber = 07969287
verify return:1
depth=0 O = breezi.com, OU = Domain Control Validated, CN = breezi.com
verify error:num=10:certificate has expired
notAfter=Sep 29 02:23:46 2013 GMT
verify return:1
depth=0 O = breezi.com, OU = Domain Control Validated, CN = breezi.com
notAfter=Sep 29 02:23:46 2013 GMT
verify return:1
---
Certificate chain
0 s:/O=breezi.com/OU=Domain Control Validated/CN=breezi.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFUzCCBDugAwIBAgIHJ84NzOXfzDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UE
BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY
BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMTMwMQYDVQQLEypodHRwOi8vY2VydGlm
aWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkxMDAuBgNVBAMTJ0dvIERhZGR5
IFNlY3VyZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTERMA8GA1UEBRMIMDc5Njky
ODcwHhcNMTIwOTI5MDIyMzQ2WhcNMTMwOTI5MDIyMzQ2WjBNMRMwEQYDVQQKEwpi
cmVlemkuY29tMSEwHwYDVQQLExhEb21haW4gQ29udHJvbCBWYWxpZGF0ZWQxEzAR
BgNVBAMTCmJyZWV6aS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDVdxshW9y7VRrN8VtPeKqfC2PXdBnxSH2Lh3jzu6ESOuQw3Jn4oFHTVNJBGxA6
v3dh607UroG9LfjN3rz+qvfmN8A7+gKtJOVM7Grc+IlTU/gy+1Ks8cs84Gsn6cq9
3yM3Qix3POf//T8q6jsYuthmzKpAcrqZizF4OFT2bDnHr2WHDDIL+BXVSBbVRgQM
r8TOtPAagiEgpjpgtSTDMTuk4fDnWolyLMW8HhBKMq2HkfoV/fD3osS0ZGgqTbwm
KnPbdAXmonMWztEr8tJe2SRdQx5HlJ5VDNgH5/ckpFnebSo0pUmthHAI5tAMiBRB
jShnAHu+GVczKuc03gYTNSQXAgMBAAGjggG4MIIBtDAPBgNVHRMBAf8EBTADAQEA
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8EBAMCBaAw
MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nb2RhZGR5LmNvbS9nZHMxLTc3
LmNybDBTBgNVHSAETDBKMEgGC2CGSAGG/W0BBxcBMDkwNwYIKwYBBQUHAgEWK2h0
dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS8wgYAGCCsG
AQUFBwEBBHQwcjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZ29kYWRkeS5jb20v
MEoGCCsGAQUFBzAChj5odHRwOi8vY2VydGlmaWNhdGVzLmdvZGFkZHkuY29tL3Jl
cG9zaXRvcnkvZ2RfaW50ZXJtZWRpYXRlLmNydDAfBgNVHSMEGDAWgBT9rGEyk2xF
1uLuhV+auud2mWjM5zAlBgNVHREEHjAcggpicmVlemkuY29tgg53d3cuYnJlZXpp
LmNvbTAdBgNVHQ4EFgQUPbIjjMZfa7Cmna7cApwl4ltIWIgwDQYJKoZIhvcNAQEF
BQADggEBAAbv7E5Gg/s0+2u4hvxHvFs5fNCT/x3QKw2AjECYM5e/jdzIBPPzA9us
zT20mDWGj/2uxoxpYg8Yjh82G68eCQ/DykKVskiR4Fiud4q9+5S+ZBsZsozNb6F8
GO2ckdhR4mDI/6xaSCzoCZljlpNXLuhOjvK3/1frxVgzbNxwERIIT8eVhBbPh7KG
3r+AQi3bbtcLJP4j0cNMHWup8FcTeRJyobjAwfOB/ot62ZeDuhtDM37wmL6XWAfw
0a0JjAD1xb8iYeKQ+aOqKTTcExdlckQFPnjfJwqk+xbXoXZGWI6pTdtTTYOOeJGu
ZXKr/ICABK8DviHq0RfVp3lnbVgfwkQ=
-----END CERTIFICATE-----
subject=/O=breezi.com/OU=Domain Control Validated/CN=breezi.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
---
No client certificate CA names sent
---
SSL handshake has read 4497 bytes and written 518 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID: 41C9F384CAB44419C20452CCBD7B7346A224F55906F943DD977198B48B44FC33
Session-ID-ctx:
Master-Key: BAD61F7C0883D5C3918DCB766C83A85FFF4C533823C5CA41C62617701E87C66C6D1351C30521B337267753B16C830BBD
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket:
0000 - 77 82 b3 42 d2 32 f9 4f-32 55 ea 03 0a 0f 66 16 w..B.2.O2U....f.
0010 - 97 8f 93 2e 47 4e ae cc-d2 a8 c0 ee 81 47 63 be ....GN.......Gc.
0020 - 07 40 fc c4 a0 28 78 e6-a2 97 22 73 87 28 77 f2 .#...(x..."s.(w.
0030 - a2 80 a3 6f d3 3c 50 cc-82 a8 0c 8e 9b 04 f0 7e ...o.<P........~
0040 - 12 24 d2 2a 9c 6b ef b8-49 d7 16 f1 45 80 e1 44 .$.*.k..I...E..D
0050 - fe d4 87 0e 92 80 b3 63-98 36 5e 9b 39 91 a3 76 .......c.6^.9..v
0060 - 3a 37 dc 1b 4d de 7e 01-22 d0 cd c0 7a 4c cf f8 :7..M.~."...zL..
0070 - ae d4 a5 fe 74 19 03 db-99 28 b7 09 ce 08 35 dd ....t....(....5.
0080 - 33 ff cd 9f 88 63 05 8a-f4 d1 f7 32 16 0b ed b9 3....c.....2....
0090 - 9f b4 ee 53 2d 8b b4 c2-27 bd b5 4d e3 19 a3 72 ...S-...'..M...r
Compression: 1 (zlib compression)
Start Time: 1393884832
Timeout : 300 (sec)
Verify return code: 10 (certificate has expired)
It's not until I did some more searching that I found out
what the error meant and that I had to do the following:
echo -n | openssl s_client -connect mywebsite.me:443 -debug | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > my.cert
echo -n | openssl s_client -connect mywebsite.me:443 -debug -CAfile my.cert
No, this is not the way to do things.
If you own the mywebsite.me domain, then you can get a free Class 1 certificate from StartCom. Their certifcates are trusted by most mobile and desktop browsers.
While StartCom does not charge to issue the certificate, they do charge for revocation because that's what costs money. (Other CAs charge you for the revocation up front and then pocket the money if not needed).
I will build a multi-client/server system. It's expected to work like this:
The client comunicates with the server using TCP/IP
When the client makes the connection to the server, the client sends a command string. When the server receives the command string, it parses it, do the required work and then sends a response to the client.
When the client closes the TCP connection, the server will destroy the resource related to this client.
The server is a multi-threaded program. The command receive, the command parse, the command deal and the response to the client may each be in a different thread.
Now, I want to define a CmdTcpContext class to contain the data related to the client.
class CmdTcpContext
18 {
19 public:
20 CmdTcpContext(){recv_buff_.SetRecvList(&recv_list_);}
21 ~CmdTcpContext(){}
22
23 CmdRecvBuffer & recv_buff(){return recv_buff_;}
24 SendBuffer & send_buff(){return send_buff_;}
25
26 RecvList<CmdPackage> & recv_list(){return recv_list_;}
27 RecvList<CmdPackage> & send_list(){return send_list_;}
28
29 InetAddr & inet_addr(){return addr_;}
30 SockStream & sock_stream(){return stream_;}
31
32 EventHandler * event_handler(){return handler_;}
33 void event_handler(EventHandler * eh){handler_ = eh;}
34 private:
35 SockStream stream_;
36 InetAddr addr_;
37
38 CmdRecvBuffer recv_buff_;
39 SendBuffer send_buff_;
40
41 RecvList<CmdPackage> recv_list_;
42 RecvList<CmdPackage> send_list_;
43
44 EventHandler *handler_;
45 };
My problem is: how can I destroy the CmdTcpContext object when the client closes the connection?