-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accessing self signed code-server on iPad #1566
Comments
Are you using a self-signed certificate? If so, you'll need to get a real one. |
Can you elaborate on what you mean by not secure? Is HTTPS not active? |
What if I'm running on LAN? As far as I know CA cannot sign |
I'd assume you'd need to setup a local CA and add that to your OS. You should also be able to add self-signed certificates to your OS, such as shown here: https://www.humankode.com/asp-net-core/develop-locally-with-https-self-signed-certificates-and-asp-net-core (Not tested) |
Hello @mbreese, thanks for pitching in but the article you linked shares how to create a simple self-signed certificate (which is by definition not signed by a CA). The problem here is not generating the certificate but the fact that in order to use code-server with iPadOS properly, an actual SSL certificate is needed. My setup is a bit more involved than normal but basically I am running code-server on a Linux box that won’t have internet connection and would allow to use vscode via iPad connected through LAN. In this scenario having an actual certificate with a domain seems out of the question and while I understand the reasoning behind limiting certain features when a self signed cert is in place (MiM attacks and such) it would still be good to have an option for intranets. |
No one ever mentioned iPadOS... that’s a bit different. But still doable. (Note: it’s recommended to use MDM for iOS).
https://support.apple.com/en-us/HT204477
You can still add the certificate to the OS so that it will be treated as trusted. The mechanism is different, but the same concept for iOS. This should still allow a self signed certificate to be used and trusted.
If you want to have multiple certificates, you should look into creating your own CA and then using that to sign your own certificates. This is pretty easy to do and there are tools available to help you manage it on Linux. The trick here is to add the CA’s certificate to each client OS (including iOS). This will by definition be a self-signed certificate.
I’ve done this for an enterprise install where our internal CA certificate gets added to each user’s system as part of deployment. Then we could issue our own certificates and have them trusted internally. This was a few years ago, so things may have changed a bit, but this is more common than you think.
Note: if you’re trying to prevent a MitM attack, you’d need some mechanism to either pin the certificate or establish that it is trusted. That’s true for a traditional server or an isolated network. Adding the certificate to the OS is one such mechanism.
|
Since iPadOS / iOS 13 there are a few more requirements for TLS server certificates to be trusted by iPadOS / iOS See https://support.apple.com/en-us/HT210176 If using openssl to issue a certificate, this blog post might help for these requirements: http://blog.nashcom.de/nashcomblog.nsf/dx/more-strict-server-certificate-handling-in-ios-13-macos-10.15.htm?opendocument&comments On macOS the certificate assistent in Keychain Access.app let's you easily create your own CA and issue the certificates. |
I have generated the certificate according to the specifications detailed by @lisanet (thanks a lot): openssl req -x509 -nodes -days 399 -sha256 -newkey rsa:2048 -out /etc/ssl/localcerts/code.crt -keyout /etc/ssl/localcerts/code.key -config /etc/ssl/openssl.cnf -addext extendedKeyUsage=serverAuth -addext subjectAltName=DNS:raspberrypi.local When I dump the certificate, as far as I can see, it complies to all the requirements (some parts have been redacted with Certificate:
Data:
Version: 3 (0x2)
Serial Number:
......
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = ES, L = Barcelona, O = Andre INC, CN = raspberrypi.local, emailAddress = ...@gmail.com
Validity
Not Before: May 3 15:26:21 2020 GMT
Not After : Jun 6 15:26:21 2021 GMT
Subject: C = ES, L = Barcelona, O = Andre INC, CN = raspberrypi.local, emailAddress = dreamorosi@gmail.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
......
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
......
X509v3 Authority Key Identifier:
keyid:......
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Subject Alternative Name:
DNS:raspberrypi.local
Signature Algorithm: sha256WithRSAEncryption
... I have then manually installed the certificate on the iPad as a profile and trusted it (thanks @mbreese) and now whenever I visit the host through Safari via HTTPS I don't get anymore any trust/security notice. Unfortunately code-server shows me a white screen after login now but at least I know it's not a certificate issue as other issues claim. |
You need to create your own CA and then create the TLS server certificate using your CA. The CA certificate has to be imported to iPadOS and has to be trusted as a profile and as a certification authority. For use with code-server, add the CA certificate to the server certificate with That fixed the white screen issue on my iPad Pro, whereas only a single self-signed server certificate didn't work. |
Could you please elaborate on how to do so through Keychain Access.app? Besides, when trying to start code-server with the |
Take a look at this: https://siber-sonic.com/mac/MailSMIME/CA.html although it seems outdated, it's still valid. And please read some manual about openssl. openssl output is almost always in PEM format, so your *.crt is just a PEM file. (test it with the 'file client.crt' command). If it is not PEM, it's in DER format, which can be easily converted, see man openssl. Well, if code-server complains about a missing key, add it with Every web server which uses TLS needs just 3 things. A server cert, the private key for this server cert, and the CA which has signed this server cert. Since code-server (and many others apps with included web servers) doesn't have an option to specify the CA cert, you need to combine it with the client cert. That's all. |
It honestly sounds like you need to run this behind a reverse proxy. Then you can let the proxy handle the SSL termination and forwarding requests to your Azure containers. This is the easiest way to get SSL running with code-server anyway (IMO). You may still have issues with To answer your specific question (and this is in no way code-server specific): you’re not going to get an IP address certificate issued to you for an ephemeral IP address you get from Azure. The only way you could potentially do it is with a self-signed CA certificate, but then you’ll still get end user warnings. See this: https://www.geocerts.com/support/ip-address-in-ssl-certificate You can have IP certificates, but no public CA would issue an IP certificate to an IP address you aren’t permanently assigned. |
@lisanet Interesting, can you not add the self signed certificate as a trusted authority like you can on macOS? |
I couldn't get it to work. I've tried using macOS certificate assistant to create a self signed root certificate with all needed extensions. Although the certificate looks okay in macOS keychain and can be trusted there, it couldn't be trusted as a root CA on iPadOS. |
Awesome, will add this to the FAQ and guide then! |
That is interesting indeed, from the previous comments I was under the impression that it was supposed to work and tested and so I spent several hours trying to make it work. @nhooyr Definitely something that should be added to the FAQs then! |
Reading my comment again, it might be somewhat misleading. A single self signed root certificate with the extension (SAN and TLS server) to use as the server certificate couldn't be trusted in iPadOS as a root certificate. Generating a root CA in macOS certificate assistant and then generating a server certificate (with the needed extensions) signed by this root CA certificate will work. The root CA cert can be trusted in iPadOS. |
Added a link to @lisanet's comment in the FAQ: https://github.com/cdr/code-server/blob/629645f55530c532bec841114bfda92550636afb/doc/FAQ.md#blank-screen-on-ipad |
@lisanet I created a CA in Certificate Assistant on the Mac. I generated a CSR using OpenSSL including the SAN (changed below to xxxxx.local): Requested Extensions: The problem I seem to have is when I "Create a Certificate For Someone Else" in Certificate Assistant, it doesn't appear to honor the SAN entry in the generated certificate. Wondering if you saw this at all when you were working through this? |
@LindsayWeir I didn't use a CSR. I used in Certificate Assistant just the "Create a Certificate" menu item with an identity type of "Leaf" and "Certificate Type" of SSL-Server and checked the "let me override defaults" to get to the extended key usage options to fill in the DNS name. |
Thanks Lisa, I was trying to use a CSR generated from OpenSSL. Let me try your way and see if that works. |
@lisanet I was able to get the certificate signed and generated correctly. This is using .local for the signed certification. Were you seeing issues with copy/paste on the iPad after you got this all working? Any insights or workarounds? Thanks |
nope, I couldn't get copy / paste to work. |
I have tried all day to get copy/paste to work with no luck. This is super fuckin’ frustrating, can we just have an override option to allow forcing the session to be considered secure??? |
They have good guides here: https://github.com/cdr/code-server/blob/v3.4.1/doc/CONTRIBUTING.md#build The upstream |
The copy/paste bug disappeared in the latest beta. |
@DAddYE thanks for pointing me in the right direction. Everything seems to be working fine now after the edit and update to latest beta! |
@DAddYE I noticed that there is no paste button on Windows or Mac. It does however appear on the ipad. I suppose the code-server should strictly be for the ipad eh. Has anyone had the same issue where the paste button doesn't appear when you right click? Thanks. |
Mmm works for me using cmd+c or cmd+v
Make sure you have the right keybidnings for your environment (mac) and
(ipad)
…On Tue, Sep 1, 2020 at 5:54 PM Andrew Phan ***@***.***> wrote:
@DAddYE <https://github.com/DAddYE> I noticed that there is no paste
button on Windows or Mac. It does however appear on the ipad. I suppose the
code-server should strictly be for the ipad eh. Has anyone had the same
issue where the paste button doesn't appear when you right click? Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1566 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAABTCJYM7TL2ATOQCNFJHLSDWJVVANCNFSM4MSQHNHQ>
.
|
There is an easy way to fix most of the above issues without any custom CA hacks. Point your domain (or sub domain) at your internal ip (such as SSH tunnels, one of those BeyondCorp VPNs like Zerotier or Tailscale, or simply localhost). Then in Caddy activate DNS-01 challenge. This does not require Caddy to be actually reachable at the domain, it just has to call the API of your registrar using one of the modules such as https://github.com/caddy-dns/cloudflare. The DNS registrar can be thought as a key-value store, your browser would be able to resolve and access the internal ip but nobody else can. |
@DAddYE I ended up following your advice and the instructions you linked from 7402.org and this was working great for iOS 13, but now that I've updated my device to iOS 14 my certs no longer pass validation. Did you have any issues getting certs to pass on your iOS 14 devices?
Please take a look at my openssl config:
|
Hmm I did not need to add any CAs to my Ipad and everything is working fine except scrolling. Copy, cut and paste works as well. I have a reverse proxy nginx server with LetsEncrypt. Copied the certs from the nginx server to my code-server machine and added this to my config.yaml in ~/.config/code-server:
You need to obviously change the cert and cert-key location to wherever your LetsEncrypt cert and key is located. Anyone else here have issues with scrolling using a magic keyboard? I have to manually click on the scroll bar and drag in order to scroll. Alternatively you can press cmd+down, which mimics the page down button. I updated by checking out the latest version and packaged it then installed the new .deb file and it updated from 3.4.1 to 3.5.0. All extensions and settings were preserved as theyre stored in ~/.local/share/code-server. |
Hi,
sorry for the late reply. Works perfectly on my end, here my config:
```
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
# Note that you can include other files from the main configuration
# file using the .include directive.
#.include filename
# This definition stops the following lines choking if HOME isn't
# defined.
HOME = .
# Extra OBJECT IDENTIFIER info:
#oid_file = $ENV::HOME/.oid
oid_section = new_oids
# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
[ new_oids ]
# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
# Policies used by the TSA examples.
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = ./demoCA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several certs with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem# The private key
x509_extensions = usr_cert # The extensions to add to the cert
# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options
# Extension copying option: use with caution.
copy_extensions = copy
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions = crl_ext
default_days = 365 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = default # use public key default MD
preserve = no # keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extensions to add to the self signed cert
# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret
# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString (PKIX recommendation before 2004)
# utf8only: only UTF8Strings (PKIX recommendation after 2004).
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings.
string_mask = utf8only
# req_extensions = v3_req # The extensions to add to a certificate request
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = AU
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Some-State
localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Internet Widgits Pty Ltd
# we can do this but it is not needed normally :-)
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName = Organizational Unit Name (eg, section)
#organizationalUnitName_default =
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64
# SET-ex3 = SET extension number 3
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ usr_cert ]
# These extensions are added when 'ca' signs a request.
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
# This is required for TSA certificates.
# extendedKeyUsage = critical,timeStamping
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
# Extensions for a typical CA
# PKIX recommendation.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = critical,CA:true
# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign
# Some might want this also
# nsCertType = sslCA, emailCA
# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
subjectAltName = DNS:daddye.local
extendedKeyUsage = serverAuth
# Copy issuer details
# issuerAltName=issuer:copy
# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF
[ crl_ext ]
# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.
# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always
[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
# This really needs to be in place for it to be a proxy certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo
####################################################################
[ tsa ]
default_tsa = tsa_config1 # the default TSA section
[ tsa_config1 ]
# These are used by the TSA reply generation only.
dir = ./demoCA # TSA root directory
serial = $dir/tsaserial # The current serial number (mandatory)
crypto_device = builtin # OpenSSL engine to use for signing
signer_cert = $dir/tsacert.pem # The TSA signing certificate
# (optional)
certs = $dir/cacert.pem # Certificate chain to include in reply
# (optional)
signer_key = $dir/private/tsakey.pem # The TSA private key (optional)
signer_digest = sha256 # Signing digest to use. (Optional)
default_policy = tsa_policy1 # Policy if request did not specify it
# (optional)
other_policies = tsa_policy2, tsa_policy3 # acceptable policies (optional)
digests = sha1, sha256, sha384, sha512 # Acceptable message digests
(mandatory)
accuracy = secs:1, millisecs:500, microsecs:100 # (optional)
clock_precision_digits = 0 # number of digits after dot. (optional)
ordering = yes # Is ordering defined for timestamps?
# (optional, default: no)
tsa_name = yes # Must the TSA name be included in the reply?
# (optional, default: no)
ess_cert_id_chain = no # Must the ESS cert id chain be included?
# (optional, default: no)
ess_cert_id_alg = sha1 # algorithm to compute certificate
# identifier (optional, default: sha1)
```
The second thing I would check is that your code serves correctly bind your
local address, because one of the recent upgrades in vscode broke it, so I
had to instead to use the local domain, to pass the local IP:
➜ co ~/.config/code-server/config.yaml
```yaml
bind-addr: 192.168.140.5:8080
auth: none
password: 0f0e1a797b62c3236d0d2888
cert: /Users/daddye/work/daddye.crt
cert-key: /Users/daddye/work/daddye.key
```
…On Fri, Sep 18, 2020 at 3:30 PM Doug Sheridan ***@***.***> wrote:
FYI, I self-signed a certificate on iOS 14 and seems working well, you
have to enable full permissions to the certificate, but other that works as
expected.
Do you have a guide for this @DAddYE <https://github.com/DAddYE> ?
Yes, I followed this:
https://7402.org/blog/2019/new-self-signed-ssl-cert-ios-13.html
Do not forget a few things:
1. From iPad don't use the local ip rather the `local-name.local` to reach your https server.
2. If out of network setup a tunnel with `Blink` (terminal for iPad) or similar apps, pay attention that only Blink has the ability to run in background and keep the tunnel open (see their docs for how to but you need to enable location tracking).
3. Once you install the certificate, don't forget to go to "Settings->General->Profiles" and enable `full access` to the new installed profile.
4. Add a home shortcut to enjoy a rather nice full screen experience:
[image: PNG image]
<https://user-images.githubusercontent.com/6537/88426313-d0869400-cda5-11ea-9144-7b9882a3f089.png>
I hope it helps!
@DAddYE <https://github.com/DAddYE> I ended up following your advice and
the instructions you linked from 7402.org and this was working great for
iOS 13, but now that I've updated my device to iOS 14 my certs no longer
pass validation. Did you have any issues getting certs to pass on your iOS
14 devices?
- I already enabled full trust for the root cert from Settings > About
> Certificate Trust Settings
- This was working in iOS 13.7 but not iOS 14
Please take a look at my openssl config:
[ ca ]
default_ca = CA_default
[ CA_default ]
default_md = sha256
default_days = 397
x509_extensions = usr_cert
[ req ]
default_bits = 4096
default_md = sha256
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca
copy_extensions = copy
[ usr_cert ]
basicConstraints=CA:TRUE
[ v3_req ]
basicConstraints = CA:TRUE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
basicConstraints = CA:TRUE
subjectAltName = DNS:10.0.1.10
extendedKeyUsage = serverAuth
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (eg, fully qualified host name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1566 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAABTCM65UILKNG4MONOJYTSGPNQBANCNFSM4MSQHNHQ>
.
|
We’re making it easier to access your code-server instance securely from any device. We’ve eliminated the need for configuring TLS, domain registration, DNS, DoS protection, and authentication. To gain pre-release access, please consider joining our alpha program. cc @DAddYE @mbreese @Tehnix @lisanet @dsherida @dreamorosi |
Now we add a subject alt name, set extendedKeyUsage and use the correct certificate extension. The above allow it to be properly trusted by iOS. See https://support.apple.com/en-us/HT210176 *.cert isn't a real extension for certificates, *.crt is correct for it to be recognized by e.g. keychain or when importing as a profile into iOS. Updates #1566 I've been able to successfully connect from my iPad Pro now to my code-server instance with a self signed certificate! Next commit will be docs.
Now we add a subject alt name, set extendedKeyUsage and use the correct certificate extension. The above allow it to be properly trusted by iOS. See https://support.apple.com/en-us/HT210176 *.cert isn't a real extension for certificates, *.crt is correct for it to be recognized by e.g. keychain or when importing as a profile into iOS. Updates #1566 I've been able to successfully connect from my iPad Pro now to my code-server instance with a self signed certificate! Next commit will be docs.
Now we add a subject alt name, set extendedKeyUsage and use the correct certificate extension. The above allow it to be properly trusted by iOS. See https://support.apple.com/en-us/HT210176 *.cert isn't a real extension for certificates, *.crt is correct for it to be recognized by e.g. keychain or when importing as a profile into iOS. Updates #1566 I've been able to successfully connect from my iPad Pro now to my code-server instance with a self signed certificate! Next commit will be docs.
This has been done and will be in the next release! |
Thanks! yes that's what I did and it works on desktop browser but on ipad I only get: and a blank screen :( ca certificate is imported in ios and trust root enabled. |
Hi @tauceti82 - sorry to hear you're still having issues! Feel free to open a new bug report issue and we'll see if we can help. Otherwise, feel free to open a Discussion if you need further help! |
i'm running code-server on https using custom image of code-server, i used existing certificate by providing the path to "--cert" and the path to its key with "--cert-key" as given documentation.
I used below command to run the code-server on https
sudo docker run -d -p 443:8080 -e PASSWORD="password@123" -v /home/ubuntu/ssl_certificate/wwwwww.crt:/home/coder/cert.crt -v /home/ubuntu/ssl_certificate/xxxxxxx.key:/home/coder/cert.key -v "$PWD:/home/coder/project" kkkkk/code-server --auth none --cert /home/coder/cert.crt --cert-key /home/coder/cert.key --proxy-domain *.yyyy.com
here in above command i'm copying my existing "certificate" and "key" from my local system to container and then passing that path in "--cert" and "--cert-key"
It's running on https and also redirecting all "http" request to "https" but the issue which is coming here is that the site in not secure even after provide correct certificate file.
what should i do to make it secure any help will be appreciated
The text was updated successfully, but these errors were encountered: