I have a a situation where the host has a SSL certificate with incorrect CN name configured. Worse still many clients connect to this service. Now there is a requirement to change the CN name in the certificate.
Here is what I am considering. Please let me know if i am missing something:
generate another certificate for the new CN, import it to JKS[Java Key Store]. By having two certificates the idea is to let clients move to the new certificates seamlessly at their own pace. once all clients migrate we remove the old certificate from the keystore. I tried doing this approach. however, when I access the service with the new CN, I get the " hostname in certificate didn't match" error. I can still access the old CN.
another approach i was thinking of having a multi-domain certificate. in this approach I will generate a new certificate with SAN name for the old CN with CN being the new name. i am hoping this will allow the clients to work with the service using both CN names. However, after this option is only feasible if the SAN referring to old CN can be deleted when all clients start using the new CN.
Related
We have a host where there are multiple websites running :
webex1dev
webex2dev
webex3dev
webex4dev
ow we have to create a certificate for all these websites. Will the sites work on ssl if we request a new certificate with CN as webex*dev?
Technically, this is allowed by RFC 2818 (and others) but is not well supported in practice.
For example, openssl does not support it at all and you are likely to run into issues with both clients and servers.
Instead, you should put the list of hosts in the Subject Alternative Name extension.
I am trying to configure a self signed ssl certificate to one of my servers. I have 3 servers. I am using 1 public ip for all three servers. To do that i am using port forwarding. I know by using openssl i can configure a self signed ssl for localhost(private network). I have below questions regarding my problem. I am using xampp in windows server.
Is it possible to configure self signed ssl certificate for a public ip-address with port? if yes
then how can i do that ?
I have seen some tutorial to configure self signed certificates but all of them are for private ip.
Meta: this is really an operations question, not programming or development, and offtopic for SO
An HTTPS server (like Apache) must use a certificate that includes the name used to access it i.e. in the URL(s) used by clients, excluding any port specification. This can be a domain name or an IP address (any kind: v4 or v6, public or private, as long as using that address from the client(s) reaches the correct server). This means that multiple servers at different ports on the same address can use the same cert if you wish, but they also be different if you prefer.
A public CA will only issue a cert containing a domainname or address you can prove you own, which is only possible for a fully-qualified domainname in public DNS or a 'permanent' public address, but for a cert you create yourself that restriction doesn't apply.
Since the turn of the century you should use the Subject Alternative Name (SAN) extension, not solely the CommonName attribute in Subject as you may find in many websites and blogs that copy outdated or incorrect information. SAN can specify more than one name if desired, but note each item in it explicitly specifies DNS or IPaddress; be sure to use the correct one(s). All popular software has supported SAN for years, but so far only Chrome(ium) requires it. OpenSSL can create certs with extensions like SAN, but not with its simplest method, which is very popular with outdated or wrong websites, namely req -new followed by basic x509 -req. See:
https://security.stackexchange.com/questions/150078/missing-x509-extensions-with-an-openssl-generated-certificate
https://unix.stackexchange.com/questions/371997/creating-a-local-ssl-certificate
https://unix.stackexchange.com/questions/393601/local-ssl-certificates-in-chrome-ium-63
PS: Windows is irrelevant, except that you probably need to install OpenSSL whereas on many Unices it is already present by default
We're currently with a webhost that has an SSL cert for us. Unfortuantely (unrelated to our webhost), we are required to move to a new host. While we setup the new host, with new temporary subdomains while we look to move, if we buy a new cert and install it on our new machines, will it "invalidate" the older one (if they cover the same domains)?
ie old webhost has cert for www.oursite.com and oursite.com. New webhost cert will cover new.oursite.com, oursite.com and www.oursite.com. If there's no DNS change until we're ready to move to the new site, will our old cert be affected?
Can multiple SSL certs be valid?
yes
will our old cert be affected
no
There is no relation between the two certificates. The browser validates the chain from the site's certificate through the CAs until it reaches a trusted (built-in) root CA.
You can either reuse the existing certificate or get a new one, if your new provider enforces it.
Multiple SSL certificates is valid for the same domain. You want to move to new host and your new host provider's giving ssl certificate with host then you should continue with new host provider certificate in place of old one. Don't pay double for ssl certificate.
My simple LDAP java program, using
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, <UserDN>);
env.put(Context.SECURITY_CREDENTIALS, <Password>);
env.put(Context.SECURITY_PROTOCOL, "ssl");
env.put(Context.PROVIDER_URL, "ldaps://<host>:636");
to make LDAP SSL authentication stopped working ever since a 2nd server certificate with the same CN but other details in the subject are different was installed on the server which I don't have access at all.
The program fails when I make the initial context
new InitialDirContext(env);
The error is "Failed to initialize directory context: <host>:636"
It returns the 2nd server certificate when I run
openssl s_client -showcerts -connect <host>:636 </dev/null
that makes me believe that the solution will be to find a way to tell the server which certificate to use.
I search and read a lot of articles on this topic and I have to admit that I am very confused, it is not clear to me if these articles are talking about client certificate or server certificate, or the actions to be taken are for the client side, or server side.
In one article, it says that I can use a custom SSLSocketFactory with the keystore path and
env.put("java.naming.ldap.factory.socket", "com.xxx.MyCustomSSLSocketFactory");
But I don't know the path to the server certificate keystore on the server.
In one Microsoft article, it says the best resolution is to have just one server certificate on the server or to put the server certificate to Active Directory Domain Services (NTDS\Personal) certificate store for LDAPS communications. But I don't have access to the server and the 'fix' to this problem has to be done in my LDAP java program.
In another article, it says to use Server Name Indication (SNI) extension.
So is there a way that I can specify which certificate I want to the server? Or my problem is somewhere else?
Thanks a lot.
Here is the stack trace:
javax.naming.ServiceUnavailableException: <host>:636; socket closed
at com.sun.jndi.ldap.Connection.readReply(Connection.java:419)
at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:340)
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:192)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2694)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
at javax.naming.InitialContext.init(InitialContext.java:223)
at javax.naming.InitialContext.<init>(InitialContext.java:197)
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)
When I used Jxplorer to run the same test, it gave me the same error.
EJP was right to point out that the issue was that the certificate was not trusted. Many thanks EJP.
When I installed the CA Certificate in %JAVA_HOME%/lib/security/cacerts, Jxplorer worked. My program still failed. I had to add these lines in it to make it work (not sure if I need all of them though ...):
System.setProperty("javax.net.ssl.keyStore",%JAVA_HOME%/lib/security/cacerts);
System.setProperty("javax.net.ssl.trustStore",%JAVA_HOME%/lib/security/cacerts);
System.setProperty("javax.net.ssl.keyStorePassword=changeit);
System.setProperty("javax.net.ssl.trustStorePassword=changeit);
But since the certificate is not trusted in the first place, I simply 'force' our server to trust it, hence this solution is not acceptable. And neither our server nor the LDAP server runs with Java 7. So SNI is out too!
EJP mentioned that I could control the server certificate by restricting the cipher suites or accepted issuers in the client (my webapp), if the server certificates have different algorithms or issuers. The 2 certificates do have different issuers, however, I don't know how to do that and I could not find anything on that neither.
EJP can you please elaborate, or point me to some sites ... ?
If the certificates have different issuers, you can control which certificate you get at the client by controlling which of those issuers is in your truststore. If only one of them is, that's the one you'll get. If they're both there, you get pot luck. Note that if your truststore also contains a common super-issuer, again it's probably pot luck.
The result isn't pot luck if you specify one and only one certificate in the Certificates - Service (Active Directory Domain Service) - NTDS\Personal location in Microsoft Management Console. Contrary to Microsoft docs I've read, though, a domain controller restart seemed to be necessary for the newly specified certificate to 'take hold'.
Hopefully the following questions will make some sense
Assume browser A wants to establish a SSL connection with web server B located at url www.xyz.com. When establishing a connection with B, A receives from the other end a X.509 certificate C. When A receives B's certificate, it checks certificate's CN field to match server B's hostname with domain name specified in certificate's CN field ( this matching is done by the browser and not by the underlying SSL connection). If B's hostname doesn't match with domain www.xyz.com, then A rejects the connection.
a) When WCF client receives a certificate C from a WCF service, does it also check C's CN field to match server's hostname with with domain name specified in CN field?
b) And vice-versa - When WCF service receives a certificate C from a WCF client, does it also check C's CN field to match client's hostname with with domain name specified in CN field?
c) If answer to the above questions is yes, then I fail to see how we can use self-signing certificates SSC with WCF, since to my knowledge SSC's CN field value doesn't match the hostname of a SSC's owner
thank you
You are correct that a self-signed (root) certificate does not often have a common name that matches a host name, although it is definitely possible, but you can use that self-signed certificate to issue a certificate with the common name that you need, eg. a host name.
Take a look at this MSDN entry: http://msdn.microsoft.com/en-us/library/ms733768.aspx