I'm having some issues with two way SSL, hoping I can find some guidance. I've tried a lot of info I've found online, and while helpful I can't get past this issue..
First some background on what I have done and how I'm setup.
IIS Server Setup:
SSL Settings:
Auth Settings:
Mapping Config:
Mapped Certs:
Bindings:
Server Cert:
Server Trusted Root:
Cert Path:
OK. So for starters I'm trying to get this to work on the server itself. I've imported the server cert into my personal store:
With the same root authority:
So... That should cover it, Right?!
Nope. I get this error in IE when I hit the site locally??
You seem to use the same certificate for the server and the client. That's not how it works.
You need to have a client certificate in your personal store. IE can't find one doesn't send one to the server. IIS then complains about it with a 403.7 because IE didn't send a client certificate.
So you need to get a client (sometimes known as SMIME) certificate from your CA and install it into your personal store.
If you look at the details of your existing certificates it should show:
Enhanced Key Usage: Server Authentication (1.3.6.1.5.5.7.3.1)
what you need there is:
Enhanced Key Usage:
Client Authentication (1.3.6.1.5.5.7.3.2)
Secure Email (1.3.6.1.5.5.7.3.4)
Related
Pulling my hair out here. Yesterday I set up an SSL Certificate in IIS10. This is the process I followed:
In IIS, under Server Certificates complete Create Certificate Request (generated server.csr & server.key)
Go to sslforfree.com and start "create certificate" process.
Enter Static IP in Domain box
In Validity, choose paste Existing CSR (paste in contents of server.csr)
Select free 90 day certificate
Choose HTTP file upload and add auth file to virtual share in IIS.
Verified OK.
Download certificate
Back in IIS, select "Complete Certificate Request"
Browse to and select "certificate.crt" file.
Give it a friendly name etc, and save.
Browse to website under sites in IIS, and select Bindings. Choose the IP of the server, the incoming Port, and the newly imported SSL certificate.
Back in sslforfree, check the installation.
Everything all good
So everything was working beautifully, could see the certificate in the browser etc, job done.
Now come to today, and the server is actively refusing requests. Go back to check the installation of my SSL on sslforfree, and it's no longer found. Tried removing and re-adding, but nothing I do seems to get the SSL to be visible.
It's not that the certificate is refused, the browser doesn't even think it's there. Why would IIS suddenly stop sharing the certificate? I am totally stumped.
EDIT
As per the advice below, I set up a DNS name with CloudFlare and pointed it at my server.
I Set up the bindings in IIS to link to the new hostname and removed the old certificate (one for port 443 and this one for port 4443 which the API runs on):
Ports 80, 443 and 4443 are all port-forwarded on the router to my server:
I then downloaded Win-ACME and successfully created the Let's Encrypt certificate, and the renewal task created in Task Scheduler.
SSL Cert now shows in Bindings:
SSL Certificate appears to be all good:
...but when I go to the site, using the new domain name. Same problem... no certificate:
So I'm not sure what the problem is here...
This issue may happens when the imported cert does not have a private key associated. solution would be to import the .CER file to your system(from where certificate is requested) personel store and export it with private key. Then copy the .pfx file to required server and import it from server certificate option under IIS.
And you can refer to this link: The Whole Story of "Server Certificate Disappears in IIS 7/7.5/8/8.5/10.0 After Installing It! Why!".
Thanks to Lex Li, I was able to dig around with Jexus Manager, and IIS Crypto to work out what was wrong.
Seems having TLS 1.2 an TLS 1.3 enabled on my machine at the same time was causing issues. Discovered this using Postman and disabling certain TLS Protocols, eventually getting it to work.
For those of you who may experience similar issues, using this application and setting it to "Best Practices" after disabling TLS 1.3 in my Registry, I finally have it working, with a certificate.
I have installed a renewed SSL certificate on my web server running IIS7.
After installation, I applied website binding to port 443.
My application uses client certificates too, so I have changed the SSL setting to Require 'client certificate'.
Both client and SSL server certificates are valid but still I am not able to access my application. The error I get is:
403 - Forbidden: Access is denied.
I have enabled client certificate mapping in IIS role settings also but still not getting rid of this 403 error.
I guess client certificate is not able to handshake with server certificate. Please help!
In certificate Store verified all server certificate and client cert with its authority hierarchy are available.
also cross check below settings
Application Authentication: Anonymous
Application SSL Setting: Require SSL/ Accept
ApplicationHost.config: enabled OnetoOneMapping under iisClientCertificateMappingAuthentication also added base64 certificate mapped with service accounts
Also based on my past experience we need to ensure we have SChannel registry setting as mentioned in below post.
https://support.microsoft.com/en-us/kb/2464556
Simplest workaround just discovered this today. In IIS for your application, Go to Edit Bindings and change your port number. 443 to 4431 or 44301. Any variation you want. In your client computer, type in the new URL using new port number and you will establish a fresh connection to application. Make sure you SSL Settings for IIS Application is set to "Accept" instead of "Require". This means you can click "Cancel" when the pop up asks you to select a certificate you can simply hit "Cancel" and still hit the site. No 403 Error.
Do not spend hours trying to mess with your certificate store, just simply change the port on IIS Server and you'll be fine.
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'.
I've tried setting up SSL for localhost running my azure web role.
What I've done is that I've created my own CA, created a client and server certificate and then installed them all in my certificate store. The server certificate is located in the local computer personal certificates, the client certificate is installed in the current user store under personal and the CA certificate is installed in trusted root certificates in both stores.
I've also configured my IIS website to use SSL and used netsh to bind the server certificate to the ip the site is running on.
However when I try to access my website through the IIS, I get an error:
HTTP Error 403.16 - Forbidden
Your client certificate is either not trusted or is invalid.
I know for a fact that the certificates I use are issued by the same CA, so I cant really see any other reason than that the IIS probably cant access my trusted root store. When I deploy my solution to azure, it works without giving me this error, so I'm positive that its a configuration issue with the local IIS that I cant work out.
Any suggestions on what could be the problem here?
I have a unique situation where I need to implement client certificate authentication over HTTPS between IE browser and IIS 6. The browser and IIS are separated by a firewall that only allows the browser to connect to IIS on the SSL port.
We have an internal certificate server on the same network as IIS. I've generated an SSL server cert for IIS and that is installed. I configured IIS to only allow SSL, require client certificates.
The limitation here is the browser machine is on a disconnected network, so I can't go to the CA's http://caserver/CertSrv URL and request a client cert like you normally would.
I figured if there were a way that I could generate a CSR against the Root CA's public key, I can copy it to the CA server to generate the client cert. But, there appears to be no provision in IE or the Certificates MMC to do this. The Certificates MMC seems to require a direct connection to the CA.
Has anyone solved this before?
FYI, All servers referenced run Windows Server 2003.
Update: Thanks to Jonas Oberschweiber and Mark Sutton for pointing out the CertReq.exe command line tool. Using this, I've generated a CSR, and consequently a client certificate that installs successfully. However, IE is apparently not sending this client cert when accessing the IIS server in question; it still generates a 403.7 "Forbidden: SSL client certificate is required." I suspect that the reason is that the Subject field of the client cert does not match the user id of the account running IE, thus perhaps not sending a mismatching client cert. The Subject matches that of the user I used to submit the CSR and generate the client cert on the other end of the firewall.
Does the Subject field matter? Is there something else I need to do to enable IE to send this cert?
Use the certreq command on your client as follows
certreq -new -f filein c:\certrequest.req
Here is and example of the filein
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject="CN=dc1.extranet.frbrikam.com"
EncipherOnly = False
Exportable = False
KeyLength = 1024
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC
[RequestAttributes]
CertificateTemplate=TLSServer
Replace the CertificateTemplate with the name of your certificate template
Once you have your request file you need to take it to the certificate authority on a usb stick and use the web enrolment interface as usual to process the request file.
Take the output certificate back to the client open it and click install.
You sound like you have already tried a couple of things so my guess is that you are already aware of these, but I'm going to post them anyway, just in case: Certificate Command Line Tools. I am not sure, however, if they do what you want.
Go the http://caserver/CertSrv site that you mentioned using a 3rd computer that can see the CA server. Select the 3rd option, download a CA cert, cert chai, or CRL. On the next page select 'Download CA Certificate Chain', which will download the p7b file. Using a flash drive (or email, etc) transfer this to the other computer which will allow you to import it into the trusted root servers in IE.
http://technet.microsoft.com/en-us/library/cc787796.aspx
Suggestiong for the update, just in case - what is the trusted cert list of in the server?
Subject DN being the same as Windows username has never been a problem for me - although I don't use IIS much. However, somewhere in IIS there is sure to be a trusted certificate list. This error sounds to me like the server's trusted certs list does not include the CA or Root CA that issued the client certificate.
This is particularly true if you never get a certificate selection popup window in IE when you hit the IIS server - even though you have a certificate configured in your IE cert store. That means that the client hit the server, the server gave a list of trusted certs and the client didn't have a cert that fit the list. So the SSL session went to the Forbidden error state.
If the certificate selection window popped up, and you selected and sent the cert, there may be other configuration problems on the server side..