All my local sites are .test but for some reason when I access some of them i get NET::ERR_CERT_COMMON_NAME_INVALID.
What's weird is that the error message points to another local environment.
This server couldn't prove that it's *****c.test; its security
certificate is from ******ing.test. This may be caused by a
misconfiguration or an attacker intercepting your connection.
I'm not sure how to resolve this. I tried deleting the certificate but nothing happened.
********ing.test Issued by: Laravel Valet CA Self Signed CN Expires: Saturday, January 21, 2023 at 17:09:55 Eastern Standard Time
"****ing.test" certificate name does not match input
I'm hiding the URL's for privacy purposes.
Fixed it by updating my updating my valet from 2.18.9 to 3.2 and running valet secure.
I tried to show js problem at my https://streamgeeks-rebranded-dev.cloudns.cl/ site
But I got a feedback from one of users :
My connection block that site ^^
The security system of the network operator blocks me saying that it is "a possible malware" –
service
sslshopper.com/ssl-checker.html#hostname=https://streamgeeks-rebranded-dev.cloudns.cl
shows :
streamgeeks-rebranded-dev.cloudns.cl resolves to 18.198.221.45 Server Type: Apache/2.4.41 (Ubuntu) The certificate should be trusted by all major web browsers (all the correct intermediate certificates are installed). The certificate was issued by Let's Encrypt. The certificate will expire in 6 days. The hostname (streamgeeks-rebranded-dev.cloudns.cl) is correctly listed in the certificate.
I run manually :
sudo certbot renew --dry-run
after that I read :
The certificate will expire in 66 days
Could you please to run my site and say if you have any problems opening it ?
Thanks!
I have a set of workstations set to use WSUS rather than windows update. Most update fine, however, in few cases, whilst client machines appear to contact the WSUS server fine, and download/apply updates, the WSUS summary does not list these IPs as ever having contacted the server.
As an example, one affected client machine shows, in windowsUpdate.log:
2017-06-03 15:57:27:352 1084 a8 Report Uploading 2 events using cached cookie, reporting URL = http:///ReportingWebService/ReportingWebService.asmx
2017-06-03 15:57:27:367 1084 a8 Report Reporter successfully uploaded 2 events.
However, the wsus_server in question shows no record of this client IP having contacted it...
Any ideas?
Ah - it looked like this was the solution:
https://blogs.technet.microsoft.com/sus/2009/05/05/resolving-the-duplicate-susclientid-issue-or-why-dont-all-my-clients-show-up-in-the-wsus-console/
It fitted the symptoms perfectly...but on trial, the solution proposed didn't do the job...
Next idea?
I have followed this article to setup an OWIN self hosted Web API within an Azure service fabric stateless service.
I also found this article which describes setting up an HTTPS endpoint within an Azure service fabric service.
...
<Certificates>
<EndpointCertificate Name="TestCert1" X509FindValue="FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0" X509StoreName="MY" />
</Certificates>
...
How do I configure the SSL certificate for my WebAPI service within service fabric? When I access my service fabric cluster in the Azure portal, the "Certificate" textboxes are greyed out.
In other Azure services their is typically a area to upload certificates which can then be referenced by the application.
Do I need to manually include my certificate in the service fabric package and install it into the certificate store before it can be referenced?
In addition does azure provide a HTTPS cert for *.cloudapp.azure.com that can be used during development?
To secure an OWIN Self-Hosted API in SF with SSL, you can follow the different scripts and example config I've compiled:
https://gist.github.com/andersosthus/c483eaf8630219c789de
The basic flow goes like this:
Upload a certificate to KeyVault (uploadCertToKeyVault.ps1)
Install the certificate to your SF VMs (installCertOnVm.ps1)
Configure the Endpoint section of your ServiceManifest
Configure the ManifestImport and Policy section of your application manifest
Step 1 & 2 can be skipped, but then you need to log in to each VM and install the certificate manually.
For VMSS:
To install certificates from KeyVault onto a VMSS with ARM, do the following:
In your VMSS template, under the OSProfile section, there is section called secrets. Here you can configure the sourcevault and add certificates to be installed.
This works like all other ARM templates. You can add a certificate to this list at a later point and redeploy the template. The certificate will then be installed on your VMSS.
Scenario: Windows server in a AD domain hosting a Subversion repository using SVNSERVE only (no Apache), and not VisualSVN.
Objective: Authenticate users to the Subversion repository via SASL through GSSAPI to a Windows domain via Kerberos.
Frequent postings in multiple sites indicate users often dead-end in this configuration with a "Could not obtain list of SASL mechanisms." I've not seen any instance where this is actually running. Does anyone have this running?
I ask this question as a result of a 2011 posting in a Gentoo forum in which someone in precisely this scenario reviewed the relevant source tarballs and concluded that while, at one time, such a configuration probably worked, the files necessary for it are no longer in the source.
GEntoo forum discussion where poster claims svnserve+gssapi+sasl worked at one time, but no longer does.
Now, I don't assert that claim to be accurate, but I do know I am stuck at precisely the same point, and I've not yet seen any posts that claim "victory" over such a setup. If you have, please advise details!
Many thanks in advance.
I've just managed (after close to 30 hours of head scratching, compiling, and sourcecode-less debugging to get decent error codes) to get svnserve+SASL+GSSAPI to work! My setup is as follows:
AD server is Samba 4.1.0 on Debian 7.2 (built from source).
Subversion server is subversion 1.8.5 on Solaris Express (SunOS 5.11 snv_151a i86pc i386 i86pc). Built for x64 from source using native (Sun) SASL.
Client is Windows 7 x64 with TortoiseSVN 1.8.2 (x64 binary release) and Heimdal 1.5.1 (x64 binary from secure-endpoints).
As with anything involving Kerberos, you need to have forward and reverse DNS working smoothly, clocks synchronized, etc.
Steps on a Windows box with domain creds:
Create a "svnserve" user account (not computer account) for the Subversion server.
Run "ktpass -princ svn/server.domain.local#DOMAIN.LOCAL -mapuser DOMAIN.LOCAL\svnserve -crypto RC4-HMAC-NT -pass password -ptype KRB5_NT_PRINCIPAL -out svnserve.keytab". You do not want to turn on DES for this account or Windows 7 will refuse to authenticate to it. I turned it on earlier (following the recipes) and had to turn it off again to get it to work.
Steps for the Subversion server:
Set up /etc/krb5/krb5.conf
[libdefaults]
default_realm = DOMAIN.LOCAL
[realms]
DOMAIN.LOCAL = {
kdc = pdc.domain.local
admin_server = pdc.domain.local
}
[domain_realm]
.domain.local = DOMAIN.LOCAL
domain.local = DOMAIN.LOCAL
# Other defaults left as-is.
Set up repo/conf/svnserve.conf:
[general]
anon-access = none
authz-db = authz
realm = DOMAIN.LOCAL
[sasl]
use-sasl = true
min-encryption = 0
max-encryption = 256
Set up repo/conf/authz:
[aliases]
[groups]
[/]
* =
# Still investigating whether access to the server can be controlled through an AD group.
# Below is for user#DOMAIN.LOCAL, the realm appears to get lost.
user = rw
Set up /etc/sasl/svn.conf:
mech_list: GSSAPI
Drop svnserve.keytab in to /etc/krb5/krb5.keytab (keytab in the sasl configuration doesn't seem to do anything).
Start svnserve.
Steps for the client:
Install TortoiseSVN and Heimdal.
Edit C:\ProgramData\Kerberos\krb5.conf to be like /etc/krb5/krb5.conf on the Subversion server. There's some other defaults in there that I left alone.
Do a checkout, no password required!
One issue with this setup is that the svnserve process has to be able to read /etc/krb5/krb5.keytab, so permissions on that need to be wound back a bit. svnserve is going in to its own zone though so this isn't an issue for me. I also had mslsa_cc.dll crashing while testing things, but I haven't seen any crashes once I got everything sorted out.
With some wrangling, you might be able to get this working for svnserve on Windows as well. I tried MIT Kerberos on the Windows client but it crashed every time on startup so I gave up on it. You might have better luck.
Update: Figured out the crash issue - it's a bug in mslsa_cc.dll (similar to https://github.com/krb5/krb5/commit/7acb524f5aa00274771dbbfac19d2dd779aad409, which also gets it slightly wrong as nOutStringLen needs to be divided by 2 for the way that ANSIToUnicode is called). Binary patch on mslsa_cc.dll is:
Offset 0xB46: Change from FF 15 04 69 00 to D1 EE 0F 1F 40.
Offset 0xB5E: Change from 77 to EB.
After earning a "tumbleweed" badge for this unanswered question, and considerable additional research on my own, I've come to the conclusion that the subject combination for Subversion under Windows is, in fact, not possible under the current code base. I believe something in the SASL authentication layer is the problem here, with some source removed or significantly changed to "break" what did, I believe, work at one point.
My solution has been to add Apache to the mix with mod_auth_sspi, and while it does slow down the repository some, the authentication works perfectly. This appears to be the "fix" for the authentication requirement.
I have done authentication against AD with SASL+LDAP, but not SASL+GSSAPI, and with a small caveat: I have to use and run svnserve from Cygwin in Windows.
1) It was quite easy to get svnserve authenticate users via SASL+LDAP/AD in Linux ( I know the question is about svnserve in Windows, but bear with me ). The important part to get the authentication working against LDAP/AD is saslauthd, and test the authentication using testsaslauthd.
Using Ubuntu as an example:
1a) /etc/sasl2/svn.conf
pwcheck_method: saslauthd
mech_list: PLAIN
This tells subversion / svnserve to use saslauthd to do the authentication on its behalf.
1b) /etc/saslauthd.conf
ldap_servers: ldap://yourADserver.dept.org
ldap_search_base: DC=dept,DC=org
ldap_bind_dn: cn=bindaccount,dc=dept,dc=org
ldap_bind_pw: passwordOfbindaccount
ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_use_sasl: no
ldap_start_tls: no
ldap_version: 3
ldap_auth_method: bind
ldap_filter: sAMAccountName=%u
ldap_password_attr: userPassword
ldap_timeout: 10
ldap_cache_ttl: 5
ldap_cache_mem: 32768
1c) Do a test via testsaslauthd
testsaslauthd -u myusername -p mypassword
1d) If successful, then run saslauthd, and start svnserve. and use whatever svn client to test the authentication.
2) Problem is, there is no native port of Cyrus' saslauthd to Windows, and probably never will be. Answer is to use Cygwin, which has svnserve, testsaslauthd, and saslauthd.
Just repeat the above steps .. but the location of svn.conf may be different.