I have a wildcard SSL from Godaddy. When I go here:
https://conciergelive.conciergeliveapp.com/users_session/new
Everything is fine. But when I go here:
https://es.conciergelive.conciergeliveapp.com/users_session/new
I get a security alert. I need the extra subdomain to determine locality. Any ideas why this does not work?
According to RFC 2818 Http Over SSL, section 3.1:
Names may contain the wildcard
character * which is considered to
match any single domain name component
or component fragment. E.g., *.a.com
matches foo.a.com but not
bar.foo.a.com
it explains why the name *.conciergeliveapp.com in the certifacte matches conciergelive.conciergeliveapp.com but not es.conciergelive.conciergeliveapp.com
Your SSL cert is really only good for *.conciergeliveapp.com, you will need another SSL cert for *.conciergelive.conciergeliveapp.com
You can reference the RFC-2818 http://www.ietf.org/rfc/rfc2818.txt
And checkout ServerFault for more detail:
https://serverfault.com/questions/104160/wildcard-ssl-certificate-for-second-level-subdomain
Related
I understand "certificate chain provided by the peer", if certificate provided by the peer is in the X509TrustManager, the certificate is trusted, so is it just need a checkTrusted instead of checkClientTrusted and checkServerTrusted, i don't understand what's the difference? Can anyone explains?
https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509TrustManager.html
void checkClientTrusted(X509Certificate[] chain, String authType):
Given the partial or complete certificate chain provided by the peer, build a certificate path to a trusted root and return if it can be validated and is trusted for client SSL authentication based on the authentication type.
void checkServerTrusted(X509Certificate[] chain, String authType):
Given the partial or complete certificate chain provided by the peer, build a certificate path to a trusted root and return if it can be validated and is trusted for server SSL authentication based on the authentication type.
In the early SSL/TLS protocols that existed when JSSE was designed, there was a significant difference between the constraints on and thus validation of server cert (linked to the key_exchange portion of the ciphersuite) versus client cert (mostly independent of key_exchange but controlled by CertReq); see rfc2246 7.4.2 and 7.4.4 (modified by rfc4492 2 and 3). Although authType is a String in both checkServer and checkClient, the values in it and the processing of them in the default TrustManager were significantly different.
TLS1.2, implemented (along with 1.1) by Java 7 and early 8, changed the cert constraints to also use a new signature_algorithms extension (from client) and field (from server) in combination with the prior fields. As a result in Java 7 up the interface you link is functionally replaced by a subtype class https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/X509ExtendedTrustManager.html which in addition to the new constraint checks also moves to the JSSE layer only in checkServer the hostname checking aka endpoint identification formerly done at a higher level like HttpsURLConnection (if at all). The extended class additionally takes an SSLSocket or SSLEngine argument (as applicable) which allows access to the additional information for sigalgs and hostname.
Finally TLS1.3, implemented in java 11 up and backported to 8u261 up, uses only extensions, now two of them, and not the ciphersuite at all, for cert selection and checking. In 1.3 the extended API is still called but the value in authType is meaningless and must not be used, and in at least some cases I have looked at is in fact empty, so the actual (rfc5280) validation is in fact the same for both directions. But as above checkServer does endpoint identification if applicable while checkClient does not.
See an actual difference in https://security.stackexchange.com/questions/158339/ssl-tls-certificate-chain-validation-result-in-invalid-authentication-type-d (note: 2017 was before TLS1.3 existed)
and compare javax.net.ssl.SSLContext to trust everything sslContext.init(keyManagerFactory.getKeyManagers(), ???, new SecureRandom()); .
I've try to apply my CA certificate to Solr. I've already reach solr with http or self-signed certificate following their own recipe in there: enabling ssl
But, when I try to apply my CA certificate I take an error : "HTTP ERROR 404 javax.servlet.UnavailableException: Error processing the request. CoreContainer is either not initialized or shutting down."
Full error message that I've take on browser
My solr.in.sh config is:
SOLR_SSL_ENABLED=true
SOLR_SSL_KEY_STORE=/etc/default/mykeystore
SOLR_SSL_KEY_STORE_PASSWORD=********
SOLR_SSL_TRUST_STORE=/etc/default/mykeystore
SOLR_SSL_TRUST_STORE_PASSWORD=********
SOLR_SSL_NEED_CLIENT_AUTH=false
# SOLR_SSL_WANT_CLIENT_AUTH=false
#SOLR_SSL_CLIENT_HOSTNAME_VERIFICATION=true
SOLR_SSL_CHECK_PEER_NAME=false
SOLR_SSL_KEY_STORE_TYPE=JKS
SOLR_SSL_TRUST_STORE_TYPE=JKS
I followed this two link for convert my pem file to key store: first:1 then:2 (I applied just fourth step in second link) then named the file as mykeystore.
I tried a lot of solution which some of them in stackoverflow. But none of them are my answer. Any help, any idea can be very useful. I'm totally stuck. What can I do/check?
I am working on a web service project which requires that clients connecting to my service authenticate themselves via X.509 certificates as part of a Mutual Authentication TLS negotiation. In addition to linking the client certificate to a specific PKI trust chain, my requirements dictate that I must verify specific values within the certificate. Specifically, the subject DN must contain one OU with a predetermined value, and the certificate must contain one subjectAltName with a different predetermined value in URI format.
I am using Apache httpd 2.4.6 on a CentOS 7 system, and am able to satisfy most of these requirements fairly easily with standard Apache configuration directives leveraging common mod_ssl variables, with one notable exception: I cannot seem to find a variable that allows me to access a subjectAltName value in URI format. Looking at the mod_ssl documentation found here:
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html
I can see variables for the following subjectAltName formats:
SSL_CLIENT_SAN_Email_n - Client certificate's subjectAltName extension entries of type rfc822Name
SSL_CLIENT_SAN_DNS_n - Client certificate's subjectAltName extension entries of type dNSName
SSL_CLIENT_SAN_OTHER_msUPN_n - Client certificate's subjectAltName extension entries of type otherName, Microsoft User Principal Name form (OID 1.3.6.1.4.1.311.20.2.3)
Given that URI is a distinct and valid format for subjectAltName values as defined in RFC 5280 (X.509/PKI) section 4.2.1.6, I'm at a loss for why mod_ssl would not provide access to subjectAltNames in this format. Is there a variable that provides this functionality which I am simply not seeing in the documentation?
Further reviewing the mod_ssl source code, it is clear that extracting SAN values in URI format for use in variables is simply not currently supported, as noted by this comment:
/*
* Not implemented right now:
* GEN_X400 (x400Address)
* GEN_DIRNAME (directoryName)
* GEN_EDIPARTY (ediPartyName)
* GEN_URI (uniformResourceIdentifier)
* GEN_IPADD (iPAddress)
* GEN_RID (registeredID)
*/
in https://github.com/apache/httpd/blob/5f32ea94af5f1e7ea68d6fca58f0ac2478cc18c5/modules/ssl/ssl_util_ssl.c
As such, the answer to my question is apparently that there is not presently a variable I can use for this purpose, and fulfilling this requirement will necessitate a workaround (or an implementation of GEN_URI pushed to mod_ssl).
I generated a golang server with go-swagger. I set the scheme to https (and only https). When I startup my server I get a TLS error.
the required flags `--tls-certificate` and `--tls-key` were not specified
It is clear that I haven't properly set my TLS flags but I really don't know the best way to to do this in go with go-swagger.
Anyone have any experience setting up TLS with go-swagger as I couldn't find any good links?
Thank you.
When you get certificates you get a private key file and a public key (certificate) file.
Here's an example of how they are used: https://github.com/go-swagger/go-swagger/tree/master/examples/todo-list#run-full-server
./todo-list-server --tls-certificate mycert1.crt --tls-key mycert1.key
I want to explicitly enable certain cipher-suites on my WildFly application server.
Therefore I tried to edit the configuration in wildflys standalone.xml.
Let's assume I want to enable the AES128-GCM-SHA256 cipher (cipher suite names from: OpenSSL documentation).
I've edited the standalone.xml file of my WildFly server like this:
<https-listener name="listener" socket-binding="https" security-realm="ssl-realm" enabled-cipher-suites="AES128-GCM-SHA256"/>
The WildFly boots up normally but when I open the page in my browser an error message appears.
Chrome says:
ERR_SSL_PROTOCOL_ERROR
Firefox says:
ssl_error_internal_error_alert
I've tried this with WildFly 8.1 and 8.2.
Anybody out there who can give my an advice how to correctly enable certain cipher-suites?
Regards Tom
You have to add a attribute called "enabled-cipher-suites" to the "https-listener" found at "subsystem undertow" -> "server".
An example for this configuration can be found here.
Unfortunately this example is wrong when it comes to the value of this attribute. You must not name such things as "ALL:!MD5:!DHA" but instead some explicit cipher suites.
You have to call em by their SSL or TLS cipher suites names and not their OpenSSL names.
So instead of "AES128-GCM-SHA256" you have to write "TLS_RSA_WITH_AES_128_GCM_SHA256".
To make the confusion complete you have to use "," instead of ":" as delimiter if you want to name more than one suite.
Regards
Ben
I can confirm Ben's answer. The documentation for how to configure this is sparse. I would suggest the following ciphers to support:
TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
in addition, the 'ALL' tag does not work and the best method is to list the ones that you wish to include and not the ones that you wish to exclude as that '!' marking does not appear to be supported.