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...
Related
Since all the certs from websites are signed by Root CA's and such, and I am writing a client, not a server, how would I create an SSLEngine that can connect to them all? or do I have to download certs and such to connect? (I am hoping that jdk has all the same info as the browsers regarding certs and such so doing this should be easy although I am having trouble with my google skills in finding it since most links are servers).
EDIT: For more clarity, I have client code like so that works with a self-signed cert. Currently, I downloaded the cert from the website I wanted through chrome clicking on the lock. I then imported that into my keystore but it's still not working...
private SSLEngine createEngine() {
try {
InputStream in = this.getClass().getResourceAsStream("/prodKeyStore.jks");
//char[] passphrase = password.toCharArray();
// First initialize the key and trust material.
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(in, "lP9Ow1uYXZr9zgt6".toCharArray());
SSLContext sslContext = SSLContext.getInstance("TLS");
//****************Client side specific*********************
// TrustManager's decide whether to allow connections.
TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
tmf.init(ks);
sslContext.init(null, tmf.getTrustManagers(), null);
//****************Client side specific*********************
SSLEngine engine = sslContext.createSSLEngine();
engine.setUseClientMode(true);
return engine;
} catch(Exception e) {
throw new RuntimeException("Could not create SSLEngine", e);
}
}
Next, I am going to try to figure out how to turn debug on for ssl exchange and see if that helps any. Currently, I am at a loss as to why this is not working.
OUCH, debug logs point to this
javax.net.ssl|DEBUG|21|httpclient2|2020-02-18 08:13:05.095 MST|CertificateMessage.java:358|Consuming server Certificate handshake message (
"Certificates": [
"certificate" : {
"version" : "v3",
"serial number" : "00 90 76 89 18 E9 33 93 A0",
"signature algorithm": "SHA256withRSA",
"issuer" : "CN=invalid2.invalid, OU="No SNI provided; please fix your client."",
"not before" : "2014-12-31 17:00:00.000 MST",
"not after" : "2029-12-31 17:00:00.000 MST",
"subject" : "CN=invalid2.invalid, OU="No SNI provided; please fix your client."",
"subject public key" : "RSA",
"extensions" : [
so something is screwing things up bigtime but not sure what yet. This is jdk8. Not sure how to fix this yet.
thanks,
Dean
It turned out there is one line wrong and it has to be this
SSLEngine engine = sslContext.createSSLEngine(host, port);
and then it all works!
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");
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.
I'm developing a C++/Windows TLS client.
I can build a certificate context for the server certificate in this way:
ReadFile(hFile, cert, 8192, &len, NULL);
CryptStringToBinary(cert, readLen, CRYPT_STRING_BASE64_ANY, binCert, &binLen, NULL, NULL);
PCCERT_CONTEXT pContext = CertCreateCertificateContext(X509_ASN_ENCODING | PKCS_7_ASN_ENCODING, (BYTE*)binCert, binLen);
but if I try do to the same with a client certificate (.pem file containing certificate and private key) I got a fail.
I think this is due to the fact that server as only one base64 section
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
while the client has two:
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY----
-----END PRIVATE KEY----
But that's just my guess.
Can someone provide a code snip that builds a certificate context from this kind of .pem file?
Acceptable code must not parse directly the file, I mean I don't want to parse the file to separate certificate from key.
Thanks!
Let me include an example of pem I would like to use:
Bag Attributes
friendlyName: client
localKeyID: 54 69 6D 65 20 31 34 38 34 38 33 33 35 35 39 31 30 39
Key Attributes: <No Attributes>
-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDMuupRTZX52zM2
1xt/3X3JhPtjtV5k4Ua+t/KFMOa0GERyJfzYFvgaKPUQWmNCkfK+oflG8IeNhoPl
+axvWckGb9Hy78M/BPyj19h96q09KpgRtPzl7QPhQUigFe7a+k6kb+unH+21bv1X
u3btN36Q/hTMHziq+EgYSuuWhDau2NQ2xgCSrJdMOox84BPaI8RqRQhL9Ob3Q5vC
ZS936NABYkBstSIMx+w9gsP6aLh+99okBa30EY9hriP8hPJ3UfIL/0ZcamCxhFOt
p3NZlI5WNz+7Gxt0Z1JtGF86fXIj65qntLDC+J2E8/6imUTA7G0KLDbgngGga2Vm
IYtckCnLAgMBAAECggEAcnJa4rBYkqAy9Qky2jvbQXgRgB+3cPVuMtdpv4MitLKM
MLODsNjGQPl8ZXPh4SjtZhvt2fZEEJ2NxlXYSzcJ5YtE9mWJ5ATJpl3XLCywQ204
LU3bwjzI2ndAPh2EtO0QYWQffAGhRLeS8CRfyyQmoK8ouSMK7qh0xP+8yxuF5h9X
1TW9wLeB3UEI0OtpaBGtOBHq06iX0BLdaszDB3cpaH3v8RCXtrtdaB2oPvMuooKf
gQFVNik7lgahMLBEXnc8BR5/LM/lxABODADU+PUvT0c8xrpi6BmOT8V5qWWsZnZC
LWTnOKSUbHz7HdTVHL1q0qMIELI7sVjL/CA4A7kRgQKBgQDxG6hfx/OYdXQaaFm5
uWexlrVNkOirwuO4Qq46rzzYnn0mSje5btBLo872sF2/5Hfkp+4PqcI+r1qM+hGe
xYl8OH1ZELXAhPVDoix9spunh7Kyaf4cxldHVh0S+aJkKuoIu8bx3UwnDjFu55zp
z8FfI7IvKziIv5cYXyG10zFtkQKBgQDZYA8Z219W9kiDc6rPuEocGATEOQ2pEu1H
1IBwjDolLAEiMQU+TfN2M/DJpsJYIIOws2aXY9bykGEC/NmlmUXp0aUrr7gvcyXQ
bVC/Tb0c//HWs5bZJx0bfM6tuaKU6t9anBSCShLk+Sr84tDX7SdP3Qtax6HQnkZ/
eMj3TSgjmwKBgQDEy4Jey2G0qwmdFFdIFGDivtQ0/3Yp2+Tq3OJA3A+Z76LOwf1B
yYUSeB3RlJqwqdaCN99DwZfeelo6f1IqeamCTslhDRaMkPlvvsr5vfL2hvgAUCst
aWaLv2nztvYpNC3Z+wqjF7G0nw0SLNIStZRsB0LE5U47r8WwCtYFBuBtQQKBgCUK
2YfuejC3h2PfMhxzqy1eanGFx24oa4byD3EedEohVZAeCmazoelisIWshTG/WLGj
4Lerq9VqBR4dOHmfxOozb5IiP6DWXntGJZx0AuYON4f+0pXutGcavZ2dJLd7ztQC
BPyu4sliLJErlas2HpzdbjHqEwkZ76mJS7XY0B5BAoGBAMiH9bMvVneJ9IOJyS0i
rosw53t9GW9m9jIKvkMyFxlyBTyrIyqOCFhnbku7wyAT8LIWqaLEWoUU1aA1Jdki
0xjnhK/3hkN1jVq66a0Oc6sOS9RY0Nobpc9sRJxbRIaunjUV/nmGqrtgQhIoOYhg
KW8xlDPBCuTaJ61PjgpFssKG
-----END PRIVATE KEY-----
Bag Attributes
friendlyName: client
localKeyID: 54 69 6D 65 20 31 34 38 34 38 33 33 35 35 39 31 30 39
subject=/C=it/ST=mi/L=milan/O=hat/OU=red/CN=clientzilla
issuer=/C=it/ST=mi/L=milan/O=hat/OU=red/CN=clientzilla
-----BEGIN CERTIFICATE-----
MIIDVzCCAj+gAwIBAgIERNkHRjANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJp
dDELMAkGA1UECBMCbWkxDjAMBgNVBAcTBW1pbGFuMQwwCgYDVQQKEwNoYXQxDDAK
BgNVBAsTA3JlZDEUMBIGA1UEAxMLY2xpZW50emlsbGEwHhcNMTcwMTE4MTczMjQz
WhcNMTcwNDE4MTczMjQzWjBcMQswCQYDVQQGEwJpdDELMAkGA1UECBMCbWkxDjAM
BgNVBAcTBW1pbGFuMQwwCgYDVQQKEwNoYXQxDDAKBgNVBAsTA3JlZDEUMBIGA1UE
AxMLY2xpZW50emlsbGEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM
uupRTZX52zM21xt/3X3JhPtjtV5k4Ua+t/KFMOa0GERyJfzYFvgaKPUQWmNCkfK+
oflG8IeNhoPl+axvWckGb9Hy78M/BPyj19h96q09KpgRtPzl7QPhQUigFe7a+k6k
b+unH+21bv1Xu3btN36Q/hTMHziq+EgYSuuWhDau2NQ2xgCSrJdMOox84BPaI8Rq
RQhL9Ob3Q5vCZS936NABYkBstSIMx+w9gsP6aLh+99okBa30EY9hriP8hPJ3UfIL
/0ZcamCxhFOtp3NZlI5WNz+7Gxt0Z1JtGF86fXIj65qntLDC+J2E8/6imUTA7G0K
LDbgngGga2VmIYtckCnLAgMBAAGjITAfMB0GA1UdDgQWBBTOFmnZVt304ZpmU2Ny
eTpalYJLZDANBgkqhkiG9w0BAQsFAAOCAQEAVquQQWQpjz4ISWdMkdHHi5zN0MzB
75PbxUKcGRx9f63sIGYlCEQ0n/GTW9ycgeF0FPxAmTxozU3G+f+cA36TRyXRzqpa
prSjWi2acfOydiI3msPohMbOkllqvmPez3sRbU8UTLL3jQX068qteLLwy0zs8plg
SRCdD87cukOjQ3PNox/88FUTAr+zVMSWfxsJ7miOxYbOFy1CVTWLpha57vP5FmA/
TkXMo3O+GLdWqWHiTDZjR84YWg9xco5NXQCETwz/LajSos2Sl2eqWAkOp7QljXs9
pu8UrmGJTO1S0Ipp5MzkmZpWx2T6E7c9zzdMzKjxjuM9f5ZEXR3tMzovvA==
-----END CERTIFICATE-----
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).