openssl s_server without PSK/certificate, but with client certificate validation

Is it possible to use openSSL without encryption and without a certificate at the server, but with validation of the client certificate? I’m not sure which cipher allows this (or where to get this info). I tried the following:


openssl s_server -cipher NULL-SHA256 -nocert -CAfile client_cert.pem -Verify 4 -verify_return_error  -accept 44330 -www   


openssl s_client -cipher NULL-SHA256 -cert client_cert.pem -key client_key.pem  -connect 

But I’m getting errors at the server and at the client:

server error:

4699434604:error:140270C1:SSL routines:ACCEPT_SR_CLNT_HELLO_C:no shared cipher:/BuildRoot/Library/Caches/ ACCEPT 

client error:

CONNECTED(00000003) 4447727212:error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure:/BuildRoot/Library/Caches/ alert number 40 4447727212:error:140040E5:SSL routines:CONNECT_CR_SRVR_HELLO:ssl handshake failure:/BuildRoot/Library/Caches/ --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session:     Protocol  : TLSv1.2     Cipher    : 0000     Session-ID:     Session-ID-ctx:     Master-Key:     Start Time: 1582732375     Timeout   : 7200 (sec)     Verify return code: 0 (ok) --- 

Is this a valid equation for determining certificate lifetimes in a PKI infrastructure?

I have an intuitive sense of how certificate lifetimes should work in a PKI infrastructure, but I don’t consider myself an expert in this field so I would like someone to validate or critique my assumptions:

The “leaves” on a PKI hierarchy are the certificates issued by a CA. The maximum lifetime of one such certificate is equivalent to:

renewal interval          + renewal period           = certificate lifetime (renew yearly, i.e. 1 yr) + (1-month renewal period) = 13 month lifetime 

An intermediate/issuing CA’s cert’s lifetime follows the same pattern, plus the maximum lifetime of a cert it can issue:

renewal interval + renewal period + child lifetime = certificate lifetime 2 years          + 1 month        + 13 months      = 3 year, 2 month lifetime 

The last step “recurses” up the PKI hierarchy through any more intermediate CA tiers until you get to the root cert.

This means, necessarily, a CA’s cert must always have a lifetime longer than the certs it issues.

Context: Apple’s Announcement about 13-month maximum cert lifetimes starting September 1st 2020 must therefore only apply to leaf certs, and not to certs issued to intermediate or root CAs.

Higher risk of no certificate pinning on mobile apps vs web apps?

Talking with people, it is frequently considered that having a mobile application without certificate pinning is a vulnerability. But i rarely see people mentioning it for web applications.

The question is, why is this issue only mentioned for mobile apps? Is there a higher risk derived out of this vulnerability on mobile apps?

Thinking about it, considering that the degree of difficulty is about the same for installing a rogue certificate on both pc and mobile, i would say that the vulnerability should exist in both cases, but in the case of web apps, there would be no remediation action since the hpkp which i think is the only way to achieve cert pinning is becoming obsolete.

Now none of the people i’ve talked with could give some reasonable explanations, so that’s why i wanted to see if there is indeed any good justification for the mobile cert pinning.

Custom certificate verification using thumbprint

I’m trying to confirm if the approach I’m thinking of taking towards verifying a self signed certificate is sound, or if I’m going about it the wrong way. I’m no security expert, so bear with me please if I make any wrong assumptions.

Following is a summary of the situation I have:

  • Self hosted Windows Service that can be running on any machine in the LAN. The service is implemented using .NET gRPC.
  • The service will only be accessed from the LAN using a desktop client. No access from a web browser or external client is involved.
  • The client uses the IP address of the host where the service is running to access it.

From a security PoV, I want to ensure that the data sent between the client and service is encrypted. To achieve this, .NET gRPC allows the use of certificates so that the client can talk to the service using HTTPS.

However, I don’t want to buy or use a CA certificate, therefore I plan to create a self signed certificate and configure the gRPC service with it.

Given that clients need to access the service through the IP address, I would need to install the certificate on every client machine. However, I don’t wish to do that. Instead I plan to leverage .NET ServerCertificateCustomValidationCallback and implement custom verification.

To verify, I am thinking of storing the certificate thumbprint/hash in the client’s code, and when the callback is invoked, verify that the received certificate thumbprint/hash matches the one in the client’s code.

Is this verification method reliable? Can a man in the middle attack occur with this method?

My initial thinking is that because it’s only the certificate hash an attacker can get hold of from the client, it won’t be possible to create a fake certificate and make the client trust it. However, I am not 100% sure.

Which has to handle certificate, a website, a web server or a web application?

In web, what is a certificate issued to, a website, a web server or a web application?

Which has to handle certificate, a website, a web server or a web application?

For example, when I run a web application on Nginx, an article shows to configure Nginx to support HTTPS and certificates.

  • I was wondering if a web application has to be implemented to support HTTPS and certificates? (I hope not, because that will make web application development simpler)

  • A web server can host multiple websites, so I was also wondering if the configuration of Nginx and the certificate are at the web server level or web site level?


Confirming the validity/ownership of a Android Signing Certificate

I have a certificate that says the application was signed by Google, but on multiple searches I have reason to believe that it’s not actually a google signing certificate.

Is there a way to query google for their approved signing certificates to check the validity?

- Issuer: CN=Android, OU=Android, O=Google Inc., L=Mountain View, ST=California, C=US - Serial number: c2e08746644a308d - Valid from: Thu Aug 21 17:13:34 MDT 2008 until: Mon Jan 07 16:13:34 MST 2036 - Certificate fingerprints: - SHA1: 38:91:8A:45:3D:07:19:93:54:F8:B1:9A:F0:5E:C6:56:2C:ED:57:88 - SHA256: F0:FD:6C:5B:41:0F:25:CB:25:C3:B5:33:46:C8:97:2F:AE:30:F8:EE:74:11:DF:91:04:80:AD:6B:2D:60:DB:83 - Signature algorithm name: MD5withRSA (weak) - Subject Public Key Algorithm: 2048-bit RSA key - Version: 3