0

I can't seem to get the Windows 10 sstp client to connect to the (router) sstp server

I have tried numerous combinations when creating my self signed certificates (ca & server) but I have to admit that I'm a little stumped

CA : https://prnt.sc/rqtkhv + https://prnt.sc/rqtks0 Server : https://prnt.sc/rqtls4 + https://prnt.sc/rqtm0y

Windows 10 : https://prnt.sc/rqtxsq + https://prnt.sc/rqtyfm

Q1) When installing the certificate in Windows I usually select [Local Computer] certificate store rather than [current user]. Is it normal for Windows to also install a copy in the [current user] store ? If so what is the point of this duplicate certificate installation ?

Q2) When installing the certificate into the "Trusted Root Certificate Authorities" for [current user] I obtain the following warning : https://prnt.sc/rqtoyb - why don't I get this same warning when installing via [Local Computer] ?

Q3) What is the meaning of the yellow triangle with exclamation mark on both [Basic Constraints] and [Key Usage] ? https://prnt.sc/rqtzj0 + https://prnt.sc/rqtzut

Q4) Why doesn't the SSTP client (https://prnt.sc/rqu1r5) detect the presence of the previously installed (sstp server's ca) certificate ? https://prnt.sc/rqu0o0

Q5) I feel like my multiple certificate installation attempts may have 'polluted' my Windows' certificate store. Is this possible ? If so is there a way to 'clean up' the certificate store (besides manually deleting unwanted certificates) ?

Q6) I believe that this used to work with Windows 10 before but, maybe because of the regular updates, things seem to have changed ?

regards yann

azurtem
  • 1
  • 2
  • Q3) Those indicate that the field is marked as critical. A critical field needs to be evaluated by the certificate client. If the certificate client does not understand the field, then it has to stop processing the certificate and treat it as untrusted. It is common and recommended to set Basic Constraints and Key Usage as critical. –  Apr 01 '20 at 13:43
  • Ok, so red herring there since it isn't an indication of an error. Thanks jnsp – azurtem Apr 01 '20 at 13:48
  • Q4) You set the sign-in info to "Certificate" that requires you to use a client certificate for authentication. Are you sure you want to sign-in with a certificate? You can select username and password instead to sign-in with those. Otherwise you have to generate client certificates that were signed by your CA. –  Apr 01 '20 at 13:48
  • I stand corrected; I read somewhere that the Windows SSTP client only required the presence of the CA. Again, thanks jnsp – azurtem Apr 01 '20 at 13:50
  • I've never used SSTP to be honest. But you should be good by just installing the CA to the local machine's trusted root store (use certlm.msc for that). You do not need to install the server's certificate to the client machine. If your SSTP server accepts username/password for sign-in, it should just work when you set your client to sign-in with those. Alternatively, you can sign-in with a client certificate. A client certificate has extended key usage set to TLS client and should be signed by your CA. Additionally, the server has to support client certificate authentication. –  Apr 01 '20 at 13:58
  • That's how I see things too but unfortunately the result isn't functional, hence Q4 & Q5 – azurtem Apr 01 '20 at 14:09
  • This question looks like an update to a question from last week, which was deleted this morning: https://security.stackexchange.com/q/227849/61443 – Mike Ounsworth Apr 01 '20 at 15:11

1 Answers1

0

The mistake I made was to set the "Type of sign-in info" to [certificate]; this needs to remain [user name and password]

The sstp server's ca certificate will is still checked by Windows 10 because that is an SSTP requirement

azurtem
  • 1
  • 2